Download the Book (PDF): Introduction In the spring of 1987 a New Jersey trial judge had to decide who the mother of a baby girl was. The child, known to the public as Baby M, had been conceived with the sperm of William Stern and the egg of Mary Beth Whitehead, who had agreed to carry the pregnancy for a fee of ten thousand dollars and then hand the child to Stern and his wife. After the birth Whitehead changed her mind. The case went to the New Jersey Supreme Court, which in 1988 declared the contract void as against public policy, called the payment something close to baby-selling, and then did what family courts always do when adults fight over a child: it asked which home served the child's best interests. The Sterns got custody. Whitehead, the child's genetic and gestational mother, kept her parental status and won visitation. Nearly four decades later, the ordinary surrogacy journey in the United States looks almost nothing like that case. The woman who carries the pregnancy is usually not genetically related to the child. The embryo was created in a laboratory, often with an egg from the intended mother or a donor, and transferred to her uterus. Before any embryo transfer took place, she and the intended parents signed a long contract negotiated by separate lawyers, underwent medical and psychological screening, and put the compensation in escrow. In a growing number of states a court will enter a judgment before the birth declaring the intended parents to be the child's only legal parents, and the hospital will print their names on the birth certificate. The child goes home with the people who planned her, and nobody goes to court to argue about it. That shift is the subject of this book. Across surrogacy, parentage and frozen embryos, American law has moved, unevenly but unmistakably, toward a single organizing principle: that in assisted reproduction the people who deliberately set out to create a child, and who recorded that intention before conception, should be treated as that child's parents and should control what happens to the embryos they made. Genetics and gestation still matter, and in some states they still decide everything. But the direction of travel is toward intention. The argument The argument of this book is that intention is now the law's governing idea in assisted reproduction, but intention protects people only when it has been captured in the right form, in the right place, before the moment it is needed. Almost every disaster in this field, from a child born with no legal mother to a divorced couple spending years in court over six frozen embryos, comes from a gap between what people meant and what they documented, or between the law of the state where they planned their family and the law of the state where something went wrong. This has practical consequences. It means a surrogacy agreement is only as good as the state whose law governs it and the court order that follows it. It means a same-sex couple whose names are both on a birth certificate may still need a court judgment to be safe in every state and every country. It means the clinic consent form a couple initialled in a waiting room, often without a lawyer, may decide the fate of their embryos a decade later in a divorce court. And it means that in a period of intense political attention to the legal status of embryos, the documents patients sign are carrying more weight than they were designed to bear. What this book covers The first chapter sets out the architecture: who regulates assisted reproduction in the United States (the short answer is that almost nobody regulates it comprehensively), the vocabulary the rest of the book relies on, and the three competing bases of legal parenthood that assisted reproduction pulls apart: genes, gestation and intention. The next three chapters deal with surrogacy and parentage. Chapter 2 maps the states, from those that have enacted detailed surrogacy statutes to the few that still treat surrogacy agreements as void, and explains how Michigan and New York, long among the most restrictive states, changed their law. Chapter 3 is about drafting: what an enforceable gestational surrogacy agreement contains, which terms courts will and will not enforce, and how the agreement should deal with the hardest questions, including selective reduction and termination in a legal environment transformed by Dobbs v. Jackson Women's Health Organization. Chapter 4 turns to the documents that actually make someone a parent in law: pre-birth and post-birth judgments, voluntary acknowledgments, birth certificates and confirmatory adoptions, and why they are not interchangeable. Chapter 5 addresses same-sex couples, for whom assisted reproduction is often the only route to a genetically related child and for whom the gap between intention and legal status has historically been widest. It explains what Obergefell v. Hodges and Pavan v. Smith guarantee, what they leave open, and why careful practitioners still recommend belt-and-braces protection. The last three chapters move to embryos. Chapter 6 asks what an embryo is in law, a question the Alabama Supreme Court answered in 2024 in a way that briefly halted IVF in that state, and examines the litigation that follows when clinics lose, destroy or mix up embryos. Chapter 7 addresses the most contested scenario in the field, the frozen embryo dispute in divorce, and explains the three approaches courts use to resolve it. Chapter 8 follows families across borders, where the gap between intention and legal recognition becomes a question of nationality and passports. The conclusion draws the threads together into a practical account of what people building families this way should do, and into an honest statement of what remains unsettled. A note on scope The law discussed here is primarily American, and American reproductive law is overwhelmingly state law. Where a point varies from state to state, which is most of the time, the book explains the range of approaches and uses particular states as examples rather than attempting a fifty-state survey that would be out of date before it was printed. Comparative material from England, Canada, Europe and elsewhere appears where it clarifies the American position or matters to families who cross borders. Two limits deserve mention. First, this is a book about the law of family formation and embryo disputes, not a medical guide and not a treatise on insurance coverage or clinic regulation, though both appear where they bear on the main argument. Second, it is written to educate, not to advise; it is not legal advice, and anyone planning a surrogacy, an embryo agreement or a cross-border arrangement needs a lawyer licensed in the relevant jurisdictions. The stakes are not abstract. The Centers for Disease Control and Prevention estimates that roughly two and a half percent of infants born in the United States each year are conceived through assisted reproductive technology, and the share has risen steadily for two decades. Behind each of those births is a set of documents, a set of assumptions about who the parents will be, and a body of law that may or may not agree with them. The rest of this book is about making sure that it does. Chapter 1: The Legal Architecture of Assisted Reproduction A patient who walks into an American fertility clinic enters one of the least comprehensively regulated corners of modern medicine. There is no federal statute that decides who may use in vitro fertilization, how many embryos may be transferred, how long embryos may be stored, or who the parents of the resulting child are. There is no federal licensing scheme for fertility clinics. What exists instead is a patchwork: a thin layer of federal rules aimed at safety and reporting, a thicker and wildly inconsistent layer of state family law, a substantial body of professional self-regulation, and, underneath it all, private contracts. Understanding how those layers fit together is the precondition for everything else in this book, because most of the legal disputes that follow arise at the seams between them. Who regulates what The federal government touches assisted reproduction in three main ways. The Food and Drug Administration regulates human cells and tissues, including sperm, eggs and embryos, under its rules for human cells, tissues and cellular and tissue-based products, codified at Part 1271 of Title 21 of the Code of Federal Regulations. Those rules require donor screening and testing for communicable diseases and impose registration and record-keeping duties on establishments that handle donated reproductive tissue. They are infection-control rules. They say nothing about who a child's parents are or whether a surrogacy agreement is valid. Second, the Fertility Clinic Success Rate and Certification Act of 1992 requires clinics to report pregnancy success rates to the Centers for Disease Control and Prevention, which publishes them. The same statute directed the development of a model program for certifying embryo laboratories that states could adopt. The reporting provisions have given the United States unusually good national data on IVF outcomes; the certification provisions have had little practical effect, and no federal agency has power to sanction a clinic for poor results or sloppy practice. Third, general federal laws apply to fertility care as they apply to any other health care: the Clinical Laboratory Improvement Amendments govern certain diagnostic testing, federal privacy law governs patient information, and federal employment and insurance law shapes whether treatment is covered. Coverage has become a live political subject. In February 2025 the President signed an executive order titled "Expanding Access to In Vitro Fertilization," directing policy recommendations on reducing costs, and in October 2025 the administration announced a pricing arrangement with a manufacturer of fertility drugs and guidance intended to make it easier for employers to offer fertility benefits separately from their main health plans. Those measures concern cost and access. None of them altered the state-law rules on parentage, surrogacy or embryo disposition that are the subject of this book. Those rules belong to the states, because family law in the United States is overwhelmingly state law. Who is a legal parent, when a contract about children is enforceable, how property is divided at divorce, and what legal status an embryo has are all questions each state answers for itself, subject only to the outer limits of the federal Constitution. That is why a surrogacy arrangement that is routine in California may be void in Nebraska, and why the same frozen embryo dispute can come out differently in New Jersey and Arizona. The third layer is professional self-regulation. The American Society for Reproductive Medicine publishes practice committee guidelines and ethics committee opinions on matters ranging from the number of embryos to transfer to the screening of gestational carriers and the handling of abandoned embryos. The Society for Assisted Reproductive Technology, affiliated with ASRM, collects outcome data from member clinics. These guidelines are not law, but they matter to law in two ways. Many state surrogacy statutes incorporate them, for example by requiring that a gestational carrier have completed a medical evaluation consistent with ASRM standards. And in malpractice and negligence litigation, professional guidelines are powerful evidence of the standard of care. State insurance law adds a further dimension, shaping who can use assisted reproduction at all. Because a single IVF cycle commonly costs well into five figures before medication, access depends heavily on coverage. A minority of states require some insurers to cover infertility treatment, and the mandates differ widely: some require coverage of IVF itself, others only diagnosis or less intensive treatment, and some merely require insurers to offer coverage that employers may decline. Illinois, Massachusetts, New Jersey and New York have among the most extensive mandates, and California enacted legislation in 2024 extending coverage requirements for large group plans, including IVF, and defining infertility broadly enough to include same-sex couples and single people. State mandates do not reach self-insured employer plans, which are governed by federal law and cover a large share of American workers, so many patients' access to IVF depends on whether their employer chooses to offer a fertility benefit. Coverage does not decide anyone's legal parentage, but it decides who ends up in the clinic signing the forms on which parentage and embryo control later depend. The fourth layer, and the one that does the most work in practice, is private ordering. Patients sign clinic consent forms that specify, among other things, what should happen to their frozen embryos if they divorce, die or stop paying storage fees. Intended parents and gestational carriers sign surrogacy agreements. Gamete donors sign donation agreements. These documents are drafted, respectively, by clinics, by lawyers and by agencies or egg banks, and they vary enormously in quality. Courts are often asked to treat them as binding contracts in circumstances their drafters never imagined. The vocabulary Assisted reproduction has generated a specialized vocabulary, and the legal consequences frequently turn on precise usage. Assisted reproductive technology, or ART, is defined by the CDC for reporting purposes as treatments in which eggs or embryos are handled outside the body. That definition includes IVF and procedures derived from it but excludes intrauterine insemination, in which sperm is placed in the uterus. Many state parentage statutes use a broader definition of "assisted reproduction" that includes insemination, because the parentage questions are the same. In vitro fertilization is the process of retrieving eggs, fertilizing them in a laboratory and culturing the resulting embryos for several days before transferring one or more to a uterus or freezing them for later use. Modern IVF produces surplus embryos as a matter of routine, because more eggs are retrieved and fertilized than will be transferred in any single cycle. Those surplus embryos, cryopreserved in liquid nitrogen, are the raw material of the disputes discussed in Chapters 6 and 7. A gestational carrier (sometimes called a gestational surrogate) carries a pregnancy that began with an embryo created from someone else's egg. She has no genetic connection to the child. A traditional surrogate conceives with her own egg, usually by insemination, and is the child's genetic mother. The distinction matters enormously. Almost every American statute that authorizes surrogacy treats gestational arrangements more permissively than traditional ones, and most practitioners and agencies decline to handle traditional surrogacy at all because the surrogate's genetic link makes her claim to parenthood much harder to extinguish. Intended parents are the people who initiate the arrangement and intend to raise the child. They may be a married or unmarried couple, same-sex or different-sex, or a single person. They may or may not have a genetic connection to the child, depending on whether their own gametes or donor gametes are used. A gamete donor provides sperm or eggs for use by someone else. An embryo donor relinquishes embryos, usually surplus embryos from their own IVF treatment, for use by another patient. Donors may be anonymous, identity-release (agreeing to disclosure when the child reaches adulthood), or known to the recipients. Finally, disposition is the term clinics use for what happens to stored embryos: continued storage, transfer to a patient, donation to another patient, donation to research, or thawing without transfer, which ends their development. Three bases of parenthood For most of legal history the question of who a child's mother was answered itself. The woman who gave birth was the mother. Paternity was harder, and the common law developed the marital presumption to deal with it: a child born to a married woman was presumed to be her husband's child. Biology determined motherhood; marriage, in most cases, determined fatherhood. Genetic testing later made it possible to prove or disprove biological paternity directly, and statutes began to give genetic evidence decisive weight in paternity actions. Assisted reproduction pulls apart three things that nature had kept together. A single child can have a genetic mother who provided the egg, a gestational mother who carried the pregnancy, and an intended mother who arranged the whole process and plans to raise the child. A child can have a genetic father who is an anonymous donor and an intended father who has no genetic link. In principle a child can have no parent who is genetically related at all, when donor egg and donor sperm are used to create an embryo carried by a gestational carrier for intended parents. Law has three candidates for deciding parenthood in these circumstances, and each has a real claim. The first is genetics. It has the attraction of objectivity and of matching what most people instinctively mean by a "real" parent. Genetic ties are what paternity statutes traditionally tested for. But a purely genetic rule produces absurd results in assisted reproduction: it would make every anonymous sperm donor the legal father of dozens of children and would deny parenthood to the intended parents who used donor gametes. The second is gestation. The woman who carries a pregnancy undergoes months of physical risk and forms a biological relationship with the fetus, and birth is a public, verifiable event. That is why the rule that the birth mother is the legal mother survived so long and remains the default in many countries, including England. But a gestational rule makes the gestational carrier the legal mother of a child she agreed to carry for someone else, which is contrary to what every party intended. The third is intention. The people who set out to bring a child into the world, and who would not have done so but for their plan to raise that child, are treated as its parents. The leading early statement of this view came from the California Supreme Court in Johnson v. Calvert in 1993. Mark and Crispina Calvert had created an embryo with their own gametes, and Anna Johnson had agreed to carry it. When the relationship broke down during the pregnancy, both Johnson and Crispina Calvert claimed to be the mother. California's parentage statute recognized both genetic evidence and giving birth as ways of establishing maternity, and here the two pointed to different women. The court held that when those two tests conflict, the woman who intended to bring about the birth of a child that she intended to raise as her own is the natural mother. Crispina Calvert was the mother; Johnson was not. Five years later a California appellate court carried the logic further. In In re Marriage of Buzzanca, decided in 1998, a married couple had arranged for an embryo created from donor egg and donor sperm to be carried by a gestational carrier. The couple separated before the birth, and the husband disclaimed responsibility. The trial court concluded that the child, Jaycee, had no legal parents at all: neither intended parent was genetically related, and the gestational carrier had never intended to be a parent. The Court of Appeal reversed, reasoning by analogy to the statute that makes a husband who consents to his wife's artificial insemination the legal father. The Buzzancas had caused Jaycee's conception and birth by initiating the surrogacy, and they were her parents. Johnson and Buzzanca were decided under statutes that did not directly address surrogacy. Since then, many states have enacted statutes that make intention the explicit basis of parenthood in assisted reproduction. The most important model is the Uniform Parentage Act, drafted by the Uniform Law Commission. Its 2002 version provided that a donor is not a parent of a child conceived by assisted reproduction, and that a person who consents to assisted reproduction by a woman with the intent to be a parent of the resulting child is a parent. Its 2017 revision made those provisions gender-neutral, so that they apply equally to same-sex couples, and substantially rewrote the surrogacy article to make gestational surrogacy agreements enforceable on stated conditions without prior court approval. The 2017 Act, or statutes modeled on it, has been adopted in a number of states, including Washington, Vermont, Rhode Island, Colorado and Connecticut, and it has influenced reforms elsewhere, including Massachusetts, which enacted a comprehensive parentage statute in 2024. Why intention is not self-executing If intention is the governing idea, why does so much still go wrong? The answer, which organizes the rest of this book, is that intention is not self-executing. A court or registrar does not know what people intended unless it is shown. The law therefore requires intention to take particular forms: a signed consent to assisted reproduction, a surrogacy agreement meeting statutory requirements, a court judgment, a voluntary acknowledgment of parentage, a clinic disposition form. Each form carries its own conditions, and each is valid only in some places for some purposes. Consider a few examples that recur throughout the chapters that follow. A consent to assisted reproduction that makes a spouse a parent under the law of one state may be meaningless in another state whose statute has not been updated to cover same-sex spouses. A surrogacy agreement that fully complies with Illinois law may be void if the parties later move to a state that prohibits such agreements and the dispute is litigated there. A birth certificate listing two intended parents is strong evidence of parentage, but it is an administrative record, not a judgment, and it does not command the full faith and credit that the Constitution guarantees to judgments of sister-state courts. A clinic form stating that embryos go to the wife on divorce may be enforced in New York and disregarded in Massachusetts. The recurring lesson is that the parties to assisted reproduction must think about intention as something to be converted into legally recognized form, with attention to which jurisdiction's law will apply and which forum will be asked to honor it. That is the work of the lawyers in this field, and it is why the practice is less about litigation than about anticipation. The chapters that follow examine each context in which that work must be done, beginning with the question that shapes every surrogacy arrangement: where is it lawful at all? Chapter 2: Where Surrogacy Is Lawful: The State Map No federal law governs surrogacy in the United States. Whether a surrogacy agreement is valid, whether the gestational carrier may be paid, and how the intended parents become the legal parents are questions each state answers for itself, and the answers range from detailed statutory schemes that treat surrogacy as an ordinary route to parenthood to statutes that declare every surrogacy contract void. For people planning a surrogacy, the choice of state is the single most consequential legal decision they will make, and it is usually made before any lawyer is consulted, when an agency matches intended parents with a carrier who happens to live somewhere. This chapter explains how the landscape developed, how it is organized today, and how practitioners decide which state's law will govern an arrangement. From Baby M to intent The modern law of surrogacy begins with In re Baby M, decided by the New Jersey Supreme Court in 1988. The introduction described the facts: a traditional surrogate, Mary Beth Whitehead, conceived by insemination with William Stern's sperm under a contract promising her ten thousand dollars, then refused to surrender the child. The court held the contract invalid for two reasons. It conflicted with New Jersey statutes forbidding payment in connection with adoption and requiring proof of parental unfitness or abandonment before parental rights could be terminated, and it offended public policy by treating a child as a commodity and binding a mother irrevocably to surrender her child before birth. The court resolved custody under the best-interests standard and gave the Sterns custody, but Whitehead remained the legal mother. Baby M had a large and immediate effect. Several state legislatures moved in the following years to prohibit or restrict surrogacy. Michigan's Surrogate Parenting Act of 1988 declared surrogacy contracts for compensation void and made participation in them a crime. New York in 1992 declared surrogacy contracts void and prohibited compensation. Other states, including Indiana and Nebraska, enacted statutes declaring surrogacy contracts void or unenforceable. Two developments turned the tide. The first was technological: the rise of gestational surrogacy, in which the carrier has no genetic tie to the child. Baby M had involved a surrogate who was the child's genetic mother, and much of its moral force came from the idea of a mother bargaining away her own child. That force weakens considerably when the carrier is gestating an embryo created from another woman's egg. Johnson v. Calvert, decided in 1993 in a gestational case, explicitly distinguished Baby M on that ground and upheld the parties' arrangement. The second development was legislative. States began to enact statutes that authorized gestational surrogacy and laid down conditions designed to protect the carrier, the intended parents and the child. Illinois enacted its Gestational Surrogacy Act in 2004, a statute that became a model for its clarity: it sets eligibility requirements for carriers and intended parents, requires independent legal counsel for each side, and establishes parentage in the intended parents by operation of law when its conditions are met, with no court proceeding required, though Illinois practitioners still routinely use administrative filings to ensure the intended parents appear on the birth certificate. Texas in 2003 amended its Family Code to permit gestational agreements that are validated by a court before the pregnancy begins. Other states followed, and the 2017 Uniform Parentage Act provided a template that several have adopted. The courts, meanwhile, continued to address surrogacy in states without statutes. The Ohio Supreme Court in J.F. v. D.B. in 2007 held that surrogacy contracts do not violate Ohio public policy. The Wisconsin Supreme Court in Rosecky v. Schissel in 2013 enforced a traditional surrogacy agreement between friends, except for its provisions on termination of parental rights, which required the procedures of the state's termination statute. The Tennessee Supreme Court in In re Baby in 2014 enforced a traditional surrogacy agreement's allocation of parental rights. The Iowa Supreme Court in P.M. v. T.B. in 2018 held that a gestational surrogacy contract was enforceable and that the carrier was not a legal parent of the child she bore. The two great reversals Two recent statutory changes, in states that had been among the most hostile to surrogacy, illustrate how far the consensus has moved. New York's prohibition on compensated surrogacy lasted nearly three decades and made the state an outlier among large, socially liberal jurisdictions. New Yorkers who wanted to use surrogacy did so in other states, most often Connecticut, New Jersey and California. After years of legislative effort, New York enacted the Child-Parent Security Act as part of its 2020 budget, and it took effect in February 2021. The statute legalized compensated gestational surrogacy, created a judicial procedure by which intended parents obtain a judgment of parentage that can be entered before the birth, and made the parentage provisions for assisted reproduction gender-neutral. It also included what it calls a Surrogates' Bill of Rights, guaranteeing the carrier the right to make all health and welfare decisions about herself and her pregnancy, including whether to terminate or continue the pregnancy or to reduce the number of fetuses, and the right to independent legal counsel of her choosing paid for by the intended parents. The statute requires that surrogacy programs be licensed and that compensation be held in escrow. It continues to exclude traditional surrogacy from its protections. Michigan's reversal was more recent. Its 1988 statute made compensated surrogacy agreements void and exposed participants to criminal penalties. In practice, intended parents who worked with Michigan carriers were forced into awkward procedures, sometimes including adoption of their own genetic children after birth. In 2024 the Michigan legislature enacted the Assisted Reproduction and Surrogacy Parentage Act, repealing the old statute, authorizing compensated surrogacy agreements, and establishing procedures for parentage judgments. The new law took effect in April 2025. With that change, the list of states that prohibit compensated surrogacy by statute became very short. The current map The fifty states and the District of Columbia can be grouped, somewhat roughly, into four categories, as Table 1 sets out. The categories are imperfect because states often combine features, and because the practical availability of court orders depends on the practices of individual judges and counties as much as on statutes. But the groupings capture how practitioners think about the landscape. Table 1. How states treat gestational surrogacy, with examples. Approach What it means in practice Examples Comprehensive statute Agreements enforceable if statutory conditions met; clear route to parentage judgment or parentage by operation of law California, Illinois, Washington, New York, Colorado, Connecticut, Michigan Permitted with conditions or court validation Agreements enforceable, but only for certain intended parents or after prior court approval Texas, Utah, Florida, Louisiana Permitted by case law or practice No comprehensive statute; courts routinely issue parentage orders Ohio, Pennsylvania, Iowa, Oregon Void or prohibited Statute declares agreements void or unenforceable; parentage must be reached by other routes Nebraska, Indiana The first category contains states with modern, comprehensive surrogacy statutes. California's is the most established: its Family Code sets requirements for the contents of a gestational surrogacy agreement, requires independent counsel for both carrier and intended parents, and permits courts to enter judgments of parentage before the birth. California has long been the destination of choice for international intended parents because its law is predictable, its courts are experienced, and it places no limitation on marital status, sexual orientation or residency. Illinois, Washington, New York, Colorado, Connecticut and now Michigan belong in the same broad category, although each has its own procedural requirements. The second category contains states that permit surrogacy but only for certain people or only through a particular procedure. Texas requires that the intended parents be married to each other, that the intended mother be medically unable to carry a pregnancy, and that the agreement be validated by a court before the embryo is transferred; an agreement not validated is unenforceable, and the intended parents may have to establish parentage through adoption. Utah's statute is similar in requiring court validation, and in 2019 the Utah Supreme Court held in In re Gestational Agreement that the statute's requirement of a medical need on the part of an intended mother could not constitutionally be applied to exclude a married male couple. Florida's statute has historically been drafted with a married couple in mind and requires a medical reason the intended mother cannot carry. Louisiana's 2016 statute is among the most restrictive of the permissive statutes: it allows gestational surrogacy only for a married couple using their own gametes, with compensation limited to reimbursement of expenses, and requires prior court approval. Arrangements outside those limits are unenforceable. The third category contains states that have no comprehensive surrogacy statute but where courts have endorsed surrogacy or routinely issue parentage orders. Ohio after J.F. v. D.B., Pennsylvania, Iowa after P.M. v. T.B., and Oregon are examples. Surrogacy in these states is common and generally smooth, but it rests on judicial practice rather than statutory guarantee, so outcomes may depend on which county the case is filed in and which judge hears it. The fourth category contains the states whose statutes declare surrogacy agreements void or unenforceable. Nebraska's statute declares compensated surrogacy contracts void and unenforceable. Indiana's statute declares surrogacy agreements void as against public policy, though Indiana courts have in practice issued orders establishing the parentage of intended parents in some gestational cases, and Indiana carriers do work with intended parents from other states under arrangements structured to be governed by another state's law. Arizona occupies an unusual position: its statute prohibiting surrogate parentage contracts remains on the books, but an Arizona appellate court in Soos v. Superior Court in 1994 held unconstitutional the part of the statute that made the surrogate the legal mother while allowing the genetic father to rebut the presumption of paternity, and in practice gestational arrangements proceed in Arizona with genetic intended parents establishing parentage through the courts. Choosing the governing state Because the law varies so much, the first legal question in any surrogacy arrangement is which state's law will govern it. Several contacts are potentially relevant: where the intended parents live, where the carrier lives, where the embryo transfer takes place, where the child will be born, and what law the agreement says governs. The contact that matters most in practice is the place of birth, for two reasons. First, the birth certificate is issued by the state where the child is born, and that state's vital records office will follow its own law about whose names to list. Second, courts in the state of birth are usually the ones asked to issue a parentage judgment, and a court applies its own state's public policy. A choice-of-law clause selecting California law will not persuade a court in a state that treats surrogacy agreements as void to enforce one. The carrier's residence matters almost as much, because the carrier will in the ordinary course deliver at a hospital near her home. That is why the "match" between intended parents and carrier is also a choice of law. Intended parents who live in a restrictive state commonly work with a carrier in a permissive state, and the child is born there. Intended parents who live in a permissive state but are matched with a carrier in a restrictive state face a more difficult question. Sometimes the carrier agrees to travel to deliver in a friendlier state, which creates medical and logistical risks and requires the agreement to address what happens if she goes into labor early at home. Sometimes practitioners rely on case law or judicial practice in the carrier's state. Many statutes also impose residency or connection requirements. Some require that at least one party reside in the state, or that the medical procedures take place there, or that the birth occur there, before a court has jurisdiction to enter a parentage order. The 2017 Uniform Parentage Act, for example, provides that a gestational surrogacy agreement is governed by the law of the state that the parties choose if that state has a sufficient connection to the arrangement, and ties court jurisdiction to connections such as the residence of a party or the place of birth. The intended parents' home state matters too, even if it plays no role in the surrogacy itself, because that is where the family will live afterward. If the home state does not recognize the parentage established in the birth state, the family may face problems years later, in custody litigation, inheritance, or school and medical decision-making. A judgment of parentage, as Chapter 4 explains, is the strongest protection against that risk, because it is entitled to full faith and credit in every state. The ethics behind the map Behind the map lies a long-running ethical argument that has not been resolved and that still shapes legislation. Critics of surrogacy argue that it commodifies women's reproductive capacity and children, that it exploits economically vulnerable women, and that it creates risks to carriers' health that money cannot justify. Some feminist scholars share these concerns; others argue that prohibiting surrogacy denies women the right to make decisions about their own bodies and labor, and that regulation protects carriers far better than prohibition, which merely drives the practice into less protected jurisdictions. The American legislative trend has favored regulation over prohibition, and the protections embedded in modern statutes reflect the critics' concerns. Minimum age requirements, a requirement that the carrier has previously given birth, medical and psychological screening, independent counsel paid for by the intended parents, escrow of compensation, and explicit guarantees of the carrier's right to make her own medical decisions are all responses to the fear of exploitation. The New York statute's Surrogates' Bill of Rights is the most explicit example. International approaches differ considerably, as Chapter 8 discusses. Many European countries prohibit surrogacy altogether, and several that permit it allow only uncompensated arrangements. The United States is unusual among wealthy democracies in permitting compensated surrogacy in most states, and that makes it a destination for intended parents from countries where surrogacy is prohibited or unavailable. For people building a family through surrogacy in the United States, the state map is therefore the first thing to understand, but only the first. Even in the most permissive state, the arrangement depends on a well-drafted agreement, which is the subject of the next chapter. Chapter 3: Drafting an Enforceable Gestational Surrogacy Agreement A gestational surrogacy agreement does two jobs at once, and much of the craft of drafting one lies in keeping them distinct. The first job is to satisfy the statutory or judicial prerequisites for establishing the intended parents' parentage and extinguishing any parental claim of the carrier and her spouse. That part of the agreement is about status, and in a state with a comprehensive statute, it is largely a matter of compliance with a checklist. The second job is to set out, as clearly as possible, what the parties expect of each other during a process that lasts a year or more and involves medical risks, large sums of money, and intimate decisions. That part of the agreement is about conduct, and it is where most of the legally difficult questions arise, because many of the promises it contains cannot be enforced in the way ordinary commercial promises can. A well-drafted agreement recognizes the difference. It is rigorous about the status provisions, because they are enforceable and their failure is catastrophic. It is candid about the conduct provisions, drafting them so that the parties have discussed and recorded their expectations, while not pretending that a court will order a woman to undergo or refuse a medical procedure. Before drafting: the prerequisites Most surrogacy statutes, and the professional guidelines that inform practice everywhere, require that several things happen before an agreement is signed. These prerequisites protect the parties, and in many states compliance with them is a condition of the agreement's enforceability. The first concerns the carrier's eligibility. The 2017 Uniform Parentage Act requires that a gestational carrier be at least twenty-one years old, have previously given birth to at least one child, have completed a medical evaluation and a mental health consultation, and have independent legal representation of her choice throughout the arrangement, paid for by the intended parents. Many state statutes impose the same or similar requirements. The American Society for Reproductive Medicine's recommendations for practices using gestational carriers, most recently updated in 2022, recommend a similar screening profile and advise that carriers ideally be between twenty-one and forty-five, have had at least one uncomplicated term delivery, and not have had more than a stated number of previous deliveries or cesarean sections. The rationale for requiring a prior birth is both medical, because it demonstrates the carrier's capacity to carry a pregnancy safely, and ethical, because a woman who has given birth has a better understanding of what she is agreeing to, including the experience of relinquishing a child after bearing it. The second concerns the intended parents. Statutes generally require that they, too, have undergone a mental health consultation and have independent legal counsel. Some statutes impose additional requirements, such as the medical-need requirement in Texas or the requirement in some states that at least one intended parent be genetically related to the child. The latter, sometimes called a genetic-link requirement, is intended to distinguish surrogacy from the purchase of a child, and in states that impose it, arrangements using donor embryos may have to proceed by adoption. The third prerequisite is independent counsel. Nearly every statute and every set of professional guidelines requires that the carrier and the intended parents be represented by separate lawyers. The carrier's lawyer, although paid by the intended parents, owes duties only to the carrier. This matters. A carrier who signs an agreement drafted by the intended parents' lawyer without independent advice is in a weak position to understand what she is giving up, and a court asked to enforce such an agreement will be skeptical of it. Independent representation also protects the intended parents, because it makes the agreement much harder to challenge later on grounds of misunderstanding or overreaching. The fourth prerequisite is timing. Almost every statute requires that the agreement be executed before any medical procedure related to the surrogacy begins, other than the screening itself. An agreement signed after the embryo transfer is typically unenforceable under the statute, and the parties may be forced into a post-birth adoption or a contested parentage proceeding. The core provisions A thorough agreement typically runs to forty or fifty pages. Its central provisions can be grouped into a handful of subjects. The parentage provisions come first in importance. The agreement states that the intended parents will be the legal parents of any child born, that the carrier and her spouse, if any, will not be parents, and that all parties will cooperate in obtaining a judgment of parentage or other documentation required under the governing state's law. It provides that the intended parents will take custody of the child immediately upon birth and assume full responsibility, including financial responsibility, for the child regardless of the child's health or number. That last point is essential and is sometimes overlooked in informal arrangements: the intended parents must agree in advance that they will accept any child born, including a child with a disability, a child of an unexpected sex, or more children than expected. Without such a clause, the carrier may be left with a child the intended parents refuse. The compensation provisions set out the base compensation, the schedule of payments, and the categories of expenses to be reimbursed. Base compensation is usually paid in monthly installments beginning after confirmation of pregnancy. Additional payments are commonly specified for particular events: the start of medications, each embryo transfer, a multiple pregnancy, an invasive procedure such as amniocentesis, a cesarean section, loss of reproductive organs, and lost wages or child care during bed rest. Reimbursement for expenses such as maternity clothing, travel, and medical costs not covered by insurance is typically handled through a monthly allowance or itemized reimbursement. Statutes generally require that compensation be reasonable and negotiated in good faith, and many require that funds be held in escrow by an independent escrow agent before the embryo transfer, so that the carrier is protected if the intended parents cannot pay. Where a state permits only uncompensated surrogacy, the agreement must limit payments to reimbursement of actual, reasonable expenses; paying more may render the agreement unenforceable or expose the parties to criminal liability. The insurance provisions deal with the carrier's medical coverage. Many health insurance policies exclude coverage for surrogate pregnancies, and an agreement must identify how the pregnancy will be covered, either through the carrier's existing policy after careful review, through a policy purchased specifically for the purpose, or through other arrangements. The agreement will also usually require the intended parents to purchase life insurance and sometimes disability insurance for the carrier, with benefits payable to her family if she dies or is disabled as a result of the pregnancy. And it should address the newborn's coverage, which is the intended parents' responsibility. The medical provisions deal with the carrier's obligations concerning prenatal care: attending appointments, following her physician's advice, abstaining from alcohol, tobacco and drugs, avoiding dangerous activities, and permitting the intended parents to attend appointments and receive medical information. They specify the number of embryos to be transferred, which is increasingly one, given the medical risks of multiple pregnancy and the professional consensus in favor of elective single-embryo transfer in suitable cases. They address the number of attempts: how many embryo transfers the carrier agrees to undergo before the agreement terminates. They address the hospital at which delivery will occur, who may be present, and the carrier's choices about pain relief and delivery method. The confidentiality and contact provisions address whether the parties will have contact after the birth and on what terms, how the child's origins will be disclosed, and what information each party may share publicly, including on social media. The termination provisions address when the agreement ends: if the carrier does not become pregnant after the agreed number of transfers, if a party dies, if the intended parents separate, and so on. They also address what happens to compensation if the agreement ends early. The contingency provisions address what happens if something goes wrong: if the intended parents die or divorce during the pregnancy, the agreement should state who will be the child's guardian, and it should state that the intended parents' obligations survive their divorce. A careful agreement cross-references wills that the intended parents execute naming a guardian for the child. The hardest clauses: termination and reduction The most sensitive provisions in any surrogacy agreement concern the possibility that the pregnancy will be ended or that the number of fetuses will be reduced. These situations arise more often than parties expect. Prenatal testing may reveal a serious genetic or structural anomaly. A multiple pregnancy may develop despite the transfer of a single embryo, because an embryo can split. The carrier's own health may be at risk. The difficulty is that intended parents and carriers may disagree about what should happen, and the law gives the carrier the final word over her own body. American courts do not order a woman to undergo an abortion, or to carry a pregnancy against her will, in order to fulfill a contract, and there is no realistic prospect that one would. The constitutional protection of bodily integrity, reflected in the common law of battery and informed consent, forbids it. The question is not whether such a clause can be specifically enforced, which it cannot, but what else follows from the carrier's decision. The answer depends on the agreement and the governing law. Some agreements provide that if the carrier declines a termination or reduction that the intended parents request on the terms the agreement contemplates, she forfeits future compensation or must repay compensation already received, or the intended parents are released from their obligation to take the child. Others provide the opposite: that if the carrier chooses to terminate in circumstances where the agreement contemplates continuation, she forfeits compensation. Statutes increasingly regulate these clauses. New York's Surrogates' Bill of Rights guarantees the carrier the right to make all health and welfare decisions regarding herself and her pregnancy, including termination or reduction, and provides that any agreement term to the contrary is unenforceable. The 2017 Uniform Parentage Act similarly provides that the carrier has the exclusive right to make all health and welfare decisions regarding herself and the pregnancy, and that an agreement may not limit her right to terminate or continue the pregnancy or to reduce the number of fetuses. Under such statutes, penalty clauses keyed to the carrier's decision are of doubtful enforceability. What the agreement can and should do is record the parties' shared understanding of the circumstances in which they would each expect termination or reduction to be considered, so that disagreement is unlikely. The case that best illustrates the stakes is C.M. v. M.C., decided by the California Court of Appeal in 2017. A gestational carrier, Melissa Cook, was carrying triplets for a single intended father in Georgia who had used donor eggs. During the pregnancy, the intended father asked Cook to reduce the pregnancy to twins, citing his financial and personal capacity; Cook refused and later sought to be declared a parent. The trial court entered a judgment of parentage in favor of the intended father, and the Court of Appeal affirmed, rejecting Cook's constitutional challenge to California's gestational surrogacy statute. A federal action raising similar arguments was dismissed. The case shows that under a comprehensive statute, a carrier's refusal to reduce does not give her a parental claim; it also shows how a disagreement about reduction, if not addressed thoroughly in advance, can lead to protracted litigation that harms everyone, including the children. After Dobbs v. Jackson Women's Health Organization in 2022 returned the regulation of abortion to the states, these clauses acquired an additional layer of complexity. In a state that prohibits abortion in most circumstances, an agreement cannot validly commit the parties to a termination that would be unlawful there, and the carrier's medical options may be constrained by the state's laws regardless of what the agreement says. Practitioners now pay close attention to where the carrier lives and where she would be able to obtain care if termination became medically advisable, and some agreements expressly address the logistics and costs of travel to another state for care, subject to whatever limits the carrier's home state imposes on assisting such travel. The law in this area is in flux, and an agreement must be reviewed against current law in the relevant states at the time of signing. What courts will and will not enforce The general principle that emerges from statutes and case law is that courts will enforce the status provisions of a compliant gestational surrogacy agreement and many of its financial provisions, but will not specifically enforce provisions that would require a person to undergo or refrain from medical procedures, and will scrutinize provisions that penalize a carrier for exercising control over her own body. Status provisions are routinely enforced in permissive states. Once the agreement complies with the statute, the intended parents are the legal parents, and the carrier cannot change her mind and claim the child. That is the central difference between the modern regime and Baby M. The carrier's protection lies in the prerequisites, not in a right to revoke. Financial provisions are enforced as ordinary contract terms, subject to statutory limits on what can be paid. A carrier who has fully performed is entitled to her compensation, and an intended parent who has paid in escrow can recover funds if the agreement terminates under its terms. Behavioral provisions concerning prenatal conduct are generally not specifically enforceable, but a breach may have financial consequences if the agreement so provides and if the consequence is not a disguised penalty for exercising a protected right. A carrier who uses illegal drugs during the pregnancy in breach of the agreement may lose compensation; a court will not order her to attend a rehabilitation program. Provisions that seek to control a carrier's decisions about termination and reduction, as discussed above, cannot be specifically enforced and, in states whose statutes guarantee the carrier's decision-making rights, cannot be enforced indirectly through penalties either. Provisions that attempt to make the intended parents' obligations conditional on the child's health are likely to be unenforceable as against public policy, and modern statutes make the intended parents responsible for the child regardless of its health or number. Remedies when things go wrong When a surrogacy arrangement fails, the remedies available depend on the nature of the breach. If a carrier refuses to relinquish the child in a state where the agreement is enforceable, the intended parents' remedy is the parentage judgment itself: they are the legal parents, and the carrier's refusal is resolved as any custody claim by a non-parent would be. If intended parents refuse to take the child, the carrier's remedy is again the parentage judgment, which makes them legally and financially responsible for the child; the agreement and the statute make clear that she is not the parent. If a party fails to pay, ordinary contract remedies apply. In a state where the agreement is void or unenforceable, the remedies are different and less predictable. The parties may be left to resolve parentage under the ordinary rules, which may make the carrier the legal mother and require an adoption or a termination of parental rights proceeding before the intended parents can become parents. Custody disputes are resolved on best interests grounds, as in Baby M. Financial disputes may be resolved on principles of unjust enrichment rather than contract. The most effective remedy is prevention: a thoroughly screened match, a candid negotiation of the difficult issues, a clear and compliant agreement, independent counsel on both sides, funds in escrow, insurance in place, and a plan for obtaining the parentage judgment. The next chapter turns to that judgment and to the other legal documents that establish parentage, and explains why the choice among them matters as much as the agreement itself. Chapter 4: Establishing Parentage: Orders, Presumptions, and Paper When a child is born through assisted reproduction, three different documents may say who the parents are, and they do not have the same legal force. A birth certificate records parentage for administrative purposes. A voluntary acknowledgment of parentage, signed at the hospital or later, establishes parentage by statute in the state where it is signed and, under federal law, must be given full faith and credit in other states. A court judgment, whether a judgment of parentage or a judgment of adoption, adjudicates parentage and binds every court in the country under the Full Faith and Credit Clause. The difference among these documents is invisible when a family is intact and stays in one state. It becomes decisive when the family moves, when the parents separate, when a parent dies, or when the family travels abroad. This chapter explains each route to legal parentage in assisted reproduction and why careful practitioners often recommend more than one. Parentage by operation of law In many states, parentage in assisted reproduction arises automatically from the facts and the statute, without any document at all. The 2017 Uniform Parentage Act and statutes modeled on it provide that an individual who consents to assisted reproduction by a woman with the intent to be a parent of the resulting child is a parent of the child. The same statutes provide that a donor is not a parent of a child conceived by assisted reproduction. And in states with comprehensive surrogacy statutes, parentage in a compliant gestational arrangement may vest in the intended parents at birth by operation of law. Illinois is the classic example: under its Gestational Surrogacy Act, if the statute's eligibility requirements are met and the agreement complies, the intended parents are the parents immediately upon birth, and the carrier and her spouse are not. The marital presumption also operates by law. In every state a child born to a married woman is presumed to be the child of her spouse. After Obergefell v. Hodges and Pavan v. Smith, discussed in Chapter 5, the presumption applies to same-sex spouses as it does to different-sex spouses, at least for the purpose of birth certificates. Many states also have a holding-out presumption, under which a person who lives with a child and openly holds the child out as his or her own for a specified period is presumed to be a parent. Parentage by operation of law has a real weakness: it is not documented anywhere except in the facts. If a later dispute arises, whether between the parents or with a third party or a court in another state, the person claiming parentage must prove the facts on which the statute depends. The consent to assisted reproduction must be proved, usually by producing a signed clinic form. The compliance of the surrogacy agreement must be proved. And the court asked to recognize the parentage must be persuaded that the law of the state where the child was born governs, rather than its own. Presumptions are rebuttable. In many states a presumption of parentage based on marriage or holding out may be challenged by genetic testing, subject to limits such as time bars or a best-interests inquiry. Statutes that deal specifically with assisted reproduction usually provide that genetic testing does not rebut the parentage of a consenting intended parent, but not every state's statute has caught up, and a presumption that seems secure in one state may be vulnerable in another. Voluntary acknowledgments of parentage Federal law requires every state, as a condition of federal child support funding, to operate a program of voluntary acknowledgment of paternity, under which an unmarried father and the mother can sign a form, usually at the hospital, that establishes paternity with the force of a judgment after a short rescission period. The statute, found in Title IV-D of the Social Security Act, also requires states to give full faith and credit to acknowledgments signed in other states. Traditionally these acknowledgments were available only to men claiming to be the genetic father. The 2017 Uniform Parentage Act expanded them into voluntary acknowledgments of parentage, available to the woman who gave birth and to an intended parent under the assisted reproduction article, regardless of gender. Several states have followed. For an unmarried same-sex couple who used donor sperm, the acknowledgment can therefore establish the non-birth mother's parentage without a court proceeding. The limits of the acknowledgment are important. First, it is available only in states whose statutes authorize it for intended parents; in states that still limit it to genetic fathers, an acknowledgment by a non-genetic parent may be void. Second, it is generally not available in surrogacy, because the birth mother, who is a party to the acknowledgment, is the carrier, and the premise of surrogacy is that the carrier is not the mother. Third, while federal law requires states to give full faith and credit to acknowledgments of paternity, there is some uncertainty about whether that obligation extends to acknowledgments of parentage by non-genetic intended parents in states that do not provide for them, and the question has not been definitively resolved. Fourth, acknowledgments may generally be challenged within a limited period on grounds of fraud, duress or material mistake of fact. Judgments of parentage: before and after birth A judgment of parentage is a court order declaring who the legal parents of a child are. In surrogacy, these judgments come in two varieties: pre-birth orders, entered during the pregnancy and effective upon birth, and post-birth orders, entered after the birth. Pre-birth orders are available in a substantial number of states, including California, Connecticut, Nevada, New York under the Child-Parent Security Act, and others. The procedure typically involves filing a petition during the second or third trimester, supported by the surrogacy agreement, declarations from the physician confirming the embryo transfer, and declarations from the carrier and her spouse consenting to the judgment. The court enters a judgment declaring the intended parents to be the legal parents of the child upon birth and directing the hospital and vital records office to list them on the birth certificate. The carrier's name never appears on the original birth certificate, and the intended parents have authority to make medical decisions for the child from the moment of birth. Post-birth orders are used in states where courts will not enter a judgment before birth, sometimes because the statute requires it, sometimes because judges take the view that there is no justiciable controversy until the child exists. The procedure is similar, but the birth certificate may initially list the carrier, and the intended parents may lack clear legal authority for the child's care in the first days of life. Well-drafted surrogacy agreements anticipate this gap by requiring the carrier to sign hospital authorizations and by specifying who will make medical decisions for the newborn. A further distinction is between orders that establish parentage for both intended parents and those that establish only a genetic parent's parentage. In some states, courts will declare a genetic intended parent to be a parent but will not so declare a non-genetic intended parent, who must then adopt. This was the result in New Jersey in In re T.J.S., which the New Jersey Supreme Court affirmed by an equally divided court in 2012. In that case a married couple had used donor eggs and the husband's sperm; the courts held that the intended mother, who had no genetic or gestational connection to the child, could not be declared the mother under the state's parentage statute and had to adopt. New Jersey later enacted the Gestational Carrier Agreement Act in 2018, which permits both intended parents to be recognized without adoption. Judgments of parentage have two decisive advantages over other routes. First, as judgments of a court, they are entitled to full faith and credit in every state. The Supreme Court has held that a judgment rendered by a court with jurisdiction must be recognized in other states even if the recognizing state disagrees with its underlying policy. In V.L. v. E.L., decided in 2016, the Alabama Supreme Court had refused to recognize a Georgia adoption judgment in favor of the same-sex partner of a child's biological mother, reasoning that the Georgia court had lacked authority under Georgia law to grant it. The United States Supreme Court summarily reversed, holding that Alabama was required to give the Georgia judgment full faith and credit. That principle applies equally to judgments of parentage. Second, judgments are ordinarily conclusive between the parties and very difficult to attack collaterally. A birth certificate can be amended; a presumption can be rebutted; a judgment, once final, stands. Birth certificates The birth certificate is the document that most people think of as establishing parentage. In law it is an administrative record, created by the vital records office of the state where the child is born. It is prima facie evidence of the facts it records, and in practice it is what schools, passport offices and hospitals rely on. But it is not a determination of parentage, and a court is not bound by it. The birth certificate matters for practical reasons. Without the right names on the certificate, the parents may have difficulty obtaining a passport, enrolling the child in health insurance, or proving authority to consent to medical care. After a surrogacy, the goal is a certificate that lists the intended parents as the only parents from the start, which is what a pre-birth order typically accomplishes. Birth certificates also have a history of discriminating against same-sex parents, which is the subject of Pavan v. Smith, discussed in the next chapter. Some states have also resisted issuing certificates listing two fathers or two mothers without a court order, and some have issued certificates with gender-specific designations that do not fit same-sex families. Most of those problems have been resolved through litigation and administrative change, but the fact that the birth certificate is merely administrative means that it can be the weak link. Adoption and confirmatory adoption Before assisted reproduction statutes caught up with families formed through donor gametes and surrogacy, adoption was often the only route by which a non-genetic intended parent could become a legal parent. A stepparent adoption or second-parent adoption allowed the partner of a legal parent to adopt the child without terminating the existing parent's rights. Second-parent adoption was a crucial tool for same-sex couples before marriage equality, and it was not available in every state. Adoption remains necessary in some circumstances: where the state's surrogacy statute does not apply to the arrangement, where the arrangement uses donor embryos in a state with a genetic-link requirement, or where the parentage statute does not cover a non-genetic intended parent. In those cases the adoption proceeding typically requires a home study, consent or termination of the rights of the legal parent being displaced, and a waiting period. Confirmatory adoption is different. It is an adoption obtained by a person who is already a legal parent, not to create parentage, but to confirm it in a judgment that commands full faith and credit. It is most commonly used by same-sex couples, and particularly by the non-birth mother in a married female couple who used donor sperm. That mother is already a legal parent under the marital presumption and, in most states, under the assisted reproduction statute. But her parentage rests on a presumption and a statute that another state, or another country, may not recognize. An adoption judgment eliminates that risk. Critics object that requiring a legal parent to adopt her own child is demeaning, expensive and intrusive, since it may involve a home study and fees, and that it implies that her parentage is otherwise inferior. The 2017 Uniform Parentage Act and several states responded by providing streamlined procedures for confirmatory adoption or for judgments of parentage in assisted reproduction without a full adoption proceeding. Massachusetts, for example, in its 2024 parentage statute, provided for judgments of parentage for children born through assisted reproduction, giving families a court order without the burdens of adoption. But where a judgment of parentage is not available, many practitioners still recommend confirmatory adoption, especially for families who may move or travel internationally. Parentage after death One situation tests every route to parentage at once: the child conceived after a parent has died. Sperm, eggs and embryos can remain viable in storage for many years, and it is now technically straightforward for a widow to conceive using her late husband's frozen sperm, or for a surviving partner to transfer embryos created before the other's death. Whether the child is the legal child of the deceased parent matters for inheritance, for Social Security survivors' benefits, and for the child's sense of identity. The Massachusetts Supreme Judicial Court addressed the question in Woodward v. Commissioner of Social Security in 2002. Lauren Woodward had conceived twins using the frozen sperm of her husband, who had died of leukemia. The court held that a posthumously conceived child may enjoy inheritance rights as the deceased parent's child under Massachusetts law, but only if the surviving parent proves a genetic relationship, and that the decedent affirmatively consented both to posthumous conception and to the support of any resulting child. It added that the claim must be brought within a reasonable time so that estates can be settled. Ten years later, in Astrue v. Capato, the United States Supreme Court held that eligibility for Social Security survivors' benefits for a posthumously conceived child depends on whether the child could inherit from the deceased parent under the intestacy law of the state where the parent was domiciled at death. Karen Capato's twins, conceived with her late husband's sperm, were denied benefits because Florida law, which governed, did not allow posthumously conceived children to inherit unless provided for in a will. The modern statutory answer, reflected in the Uniform Parentage Act and the Uniform Probate Code, follows Woodward's logic: a deceased individual is a parent of a child conceived by assisted reproduction after death if he or she consented in a signed record, or the intent is otherwise established by clear and convincing evidence, and if the embryo is in utero or the child is born within a stated period after death. The practical lesson is the one that runs through this book. A person who stores gametes or embryos should say in writing, in the clinic's forms and in his or her estate plan, whether posthumous use is authorized, by whom, and with what consequences for parentage. Without that record, the survivor's certainty about what the deceased would have wanted counts for very little. Comparing the routes The various routes to legal parentage differ in their availability, their procedural burdens, and above all their portability across state and national lines. Table 2 summarizes the main differences. Table 2. Routes to legal parentage in assisted reproduction. Route How obtained Court involved Portability Operation of law Statute plus facts (consent, compliant agreement) No Depends on other state accepting governing law Marital or holding-out presumption Marriage at birth, or living with and holding out child No Recognized widely but rebuttable in some states Voluntary acknowledgment Signed form, usually at hospital No Full faith and credit by federal statute, with open questions for non-genetic parents Judgment of parentage Petition before or after birth Yes Full faith and credit as a judgment Adoption (including confirmatory) Petition, often with home study Yes Full faith and credit as a judgment; widely recognized abroad The principle that emerges is simple: a judgment is the strongest protection, and the others are progressively weaker. In a state with a comprehensive statute and a straightforward family, a judgment may be unnecessary; the family is secure under the statute and the birth certificate. But families move, relationships end, parents die, and children travel. Whenever parentage rests on something other than a judgment, it is exposed to the possibility that a court somewhere, applying its own law, will reach a different conclusion. That possibility has been most acute for same-sex couples, whose family forms were for decades denied recognition, and whose position is the subject of the next chapter. Chapter 5: Same-Sex Couples and the Constitutional Floor For same-sex couples, assisted reproduction is not an alternative route to parenthood; it is very often the only route to a child genetically related to either of them. A female couple needs donor sperm. A male couple needs an egg donor and a gestational carrier. In every case at least one intended parent has no genetic connection to the child, and in the case of a female couple using one partner's egg and the other partner's uterus, the two women divide genetic and gestational motherhood between them. The law of parentage, built on marriage between a man and a woman and on the assumption that the birth mother's husband is presumptively the father, was not designed with these families in mind. The history of same-sex parentage law is therefore the history of the gap between intention and legal status at its widest. It is also the area in which that gap has closed most dramatically over the past two decades, through a combination of state statutes, state court decisions and, after 2015, federal constitutional law. This chapter explains what the Constitution now guarantees, what it leaves to the states, and why the practical advice to same-sex parents has not changed as much as the law. Before Obergefell Before marriage equality, same-sex couples relied on a patchwork of state doctrines to secure the parentage of the non-biological parent. The most important was second-parent adoption, which allowed a legal parent's partner to adopt without terminating the legal parent's rights. Courts in states including Massachusetts, New York, Vermont and California approved second-parent adoptions in the 1990s and early 2000s, but courts in other states refused, and some legislatures prohibited them. A second doctrine treated the non-biological partner as a parent on the basis of intent and conduct. California took the lead. In Elisa B. v. Superior Court, decided in 2005, the California Supreme Court held that a woman who had agreed to raise children with her partner, who had actively participated in bringing them into the world through artificial insemination, and who had held them out as her own was a presumed parent under the Uniform Parentage Act as adopted in California, and was obligated to pay child support after the couple separated. In the companion case K.M. v. E.G., also decided in 2005, the court held that a woman who provided her eggs to her female partner, so that the partner could bear children the couple would raise together, was a legal parent of the resulting twins, notwithstanding a form she had signed at the clinic waiving parental rights as an egg donor. The court reasoned that she had not intended to donate her eggs to someone else but to produce children within her own relationship. That arrangement, in which one woman provides the egg and the other carries the pregnancy, is now commonly called reciprocal IVF, and K.M. is the leading case establishing that both women can be mothers. Other states were far less receptive. For many years New York's highest court followed Alison D. v. Virginia M., a 1991 decision holding that a woman who had planned and raised a child with her former partner, but who was neither the biological nor adoptive mother, lacked standing to seek visitation. It took until 2016 for the New York Court of Appeals, in Brooke S.B. v. Elizabeth A.C.C., to overrule Alison D., holding that where a partner shows by clear and convincing evidence that the couple agreed to conceive a child and to raise the child together, the non-biological, non-adoptive partner has standing to seek custody and visitation as a parent. What the Constitution now guarantees The Supreme Court's decision in Obergefell v. Hodges in 2015 held that the Fourteenth Amendment requires states to license marriages between same-sex couples and to recognize same-sex marriages lawfully performed elsewhere. The majority opinion listed among the reasons for protecting the right to marry that marriage safeguards children and families, and it included among the benefits of marriage the rules governing birth and death certificates. It did not address parentage directly. Two years later, in Pavan v. Smith, the Court did. Arkansas's birth certificate statute provided that when a married woman gives birth, her husband is listed as the father, including when the child was conceived through artificial insemination with donor sperm. Arkansas refused to list the female spouse of a birth mother on the birth certificate on the same terms. The Arkansas Supreme Court upheld the refusal on the ground that birth certificates record biological relationships. The United States Supreme Court summarily reversed in a per curiam opinion, holding that Arkansas's differential treatment of same-sex spouses infringed the constitutional guarantee recognized in Obergefell. Because Arkansas listed a birth mother's husband as the father even when he was not the biological father, the birth certificate was not simply a record of biology, and Arkansas could not deny married same-sex couples the same benefit. Lower courts have applied Obergefell and Pavan to require equal treatment of same-sex spouses in the application of the marital presumption. The Arizona Supreme Court in McLaughlin v. Jones, decided in 2017, held that the state's marital paternity presumption, which was framed in terms of a husband, had to be applied to the female spouse of a birth mother, and that the non-biological mother could not be denied parental status after the couple separated. The Seventh Circuit in Henderson v. Box, decided in 2020, held that Indiana had to list both married mothers on the birth certificate of a child born to one of them. The Massachusetts Supreme Judicial Court, in Partanen v. Gallagher in 2016, held that the state's holding-out presumption could apply to an unmarried woman who had no biological connection to the children she had raised with her former partner, reading the gendered language of the statute to apply equally to women. The constitutional floor, then, is this: a state must extend to married same-sex couples the parentage rules that it extends to married different-sex couples, including the marital presumption and the rules governing birth certificates, at least where those rules are not strictly tied to biology. A state that presumes a husband to be the father of his wife's child conceived with donor sperm must presume a wife to be the parent of her wife's child conceived the same way. What the Constitution does not guarantee That floor leaves several important questions to the states. First, Pavan was about married couples. The Constitution as interpreted so far does not require a state to recognize an unmarried non-biological partner as a parent. Unmarried couples must rely on the state's parentage statute, a voluntary acknowledgment if the state permits one for intended parents, a holding-out presumption, or a court order. States differ considerably on each. Second, the marital presumption remains rebuttable in many states, and the rules for rebutting it vary. If a state permits genetic evidence to rebut a husband's paternity in some circumstances, a court may reason that a wife's presumed parentage, which can never be supported by genetic evidence, is more vulnerable than a husband's. Most states have addressed this through their assisted reproduction statutes, which provide that a spouse who consents to assisted reproduction is a parent regardless of genetics. But not every state's statute is gender-neutral, and in states where it is not, the protection depends on courts extending Obergefell and Pavan, which most, but not necessarily all, would do. Third, the constitutional principle does not directly resolve how surrogacy law applies to male couples. A male couple cannot rely on the marital presumption, because neither man gave birth. They must rely on the state's surrogacy law, which may contain provisions framed around an intended mother. The Utah Supreme Court's decision in In re Gestational Agreement in 2019 held that Utah's requirement of medical evidence that the intended mother was unable to bear a child could not be applied to exclude a married male couple, because doing so would deny them equal treatment under Obergefell and Pavan. That is a significant precedent, but not every state has considered the question, and a statute requiring an intended mother's medical need, such as the Texas and Florida statutes, poses at least a question for male couples, which is why many male couples choose to work with carriers in states whose statutes are gender-neutral. Fourth, and perhaps most importantly, the durability of the constitutional floor depends on Obergefell itself. In Dobbs v. Jackson Women's Health Organization in 2022, the Court overruled Roe v. Wade, holding that the Due Process Clause does not protect a right to abortion because such a right is not deeply rooted in the nation's history and tradition. The majority stated that its decision concerned abortion alone and should not be understood to cast doubt on precedents that do not concern abortion. A concurring opinion by Justice Thomas, however, suggested that the Court should reconsider all of its substantive due process precedents, naming Obergefell among them. Congress responded later in 2022 with the Respect for Marriage Act, which repealed the Defense of Marriage Act and requires federal recognition of valid marriages and state recognition of marriages validly performed in other states, though it does not require any state to license same-sex marriages if Obergefell were overruled. The Supreme Court in late 2025 declined to hear a petition that asked it to revisit Obergefell. The constitutional floor is therefore intact, but the fact that it is being tested reinforces the practical advice that same-sex parents should not rely on it alone. The known-donor problem A distinct risk for female couples, and for single women, arises when they use sperm from a known donor, such as a friend, rather than from a sperm bank. The legal question is whether the donor is a parent. The original 1973 Uniform Parentage Act provided that a man who provides semen to a licensed physician for use in artificial insemination of a married woman other than his wife is treated as if he were not the father. Many states adopted that provision, and some still have it. It creates two traps. It applied only to married women, so a donor to an unmarried woman was not protected by its terms. And it applied only where the semen was provided to a licensed physician, so a donor who provided semen for home insemination fell outside the statute. In Jhordan C. v. Mary K., decided by a California appellate court in 1986, a known donor who provided semen directly to a woman who inseminated at home was held to be the legal father because the statute's physician requirement was not satisfied. Kansas's highest court, in In re K.M.H. in 2007, upheld a donor statute that required a written agreement for a known donor to be a parent, and applied it against a donor who claimed parental rights without one. Modern statutes based on the 2002 and 2017 Uniform Parentage Acts eliminate both traps: a donor is not a parent of a child conceived by assisted reproduction, whether or not the recipient is married and whether or not a physician is involved, unless the parties agree otherwise in a signed record. But in states with older statutes, a known-donor arrangement without medical involvement can leave the donor as a legal parent, with the right to seek custody and the obligation to pay support. Even in states with modern statutes, a known donor who becomes involved in the child's life may later assert a claim based on holding out or on a de facto parentage doctrine. The protective steps are straightforward: a written donor agreement, drafted with separate counsel, stating that the donor is not intended to be a parent; insemination through a clinic where state law makes that relevant; and, for the non-biological parent, a judgment of parentage or confirmatory adoption. Citizenship for children born abroad Same-sex couples face a specific problem when their children are born abroad through surrogacy or assisted reproduction, and the problem illustrates how intention and genetics can collide in federal law. The Immigration and Nationality Act provides different rules for children born abroad "in wedlock" and "out of wedlock." For years the State Department interpreted "in wedlock" to require a biological relationship between the child and both married parents, so a child born abroad through surrogacy to a married male couple, conceived with the sperm of the non-citizen spouse, was treated as born out of wedlock and not entitled to citizenship at birth through the citizen spouse. Several families challenged the policy. In Kiviti v. Pompeo, decided in 2020, a federal district court in Maryland held that the child of a married male couple, born abroad through surrogacy, was a citizen at birth because the statute's references to parents and wedlock did not require a biological relationship with both parents. Similar rulings were issued elsewhere. In May 2021 the State Department changed its policy, announcing that a child born abroad to married parents, at least one of whom is a US citizen, can acquire citizenship at birth if the child is biologically related to at least one parent, even if not to the citizen parent. The change resolved the problem for most married same-sex couples, but it is a policy interpretation rather than a statutory amendment, and it does not address children with no biological relationship to either parent. The practical advice The combined effect of these developments is that a same-sex couple in the United States is far more secure than at any time in history, but the gap between intention and legal status has not disappeared. It persists at the margins: in states with outdated statutes, for unmarried couples, for families with known donors, for male couples in states with gendered surrogacy laws, and for families who travel or move abroad, where American parentage presumptions may not be recognized. Practitioners' advice has therefore remained largely unchanged since before Obergefell: secure a judgment. For a married female couple, that usually means a judgment of parentage where the state provides one, or a confirmatory adoption where it does not. For a male couple using surrogacy, it means a judgment of parentage in the state of birth that names both fathers. For an unmarried couple, it means a judgment, because the marital presumption is unavailable. The cost and inconvenience are real, but the protection is complete: a judgment is entitled to full faith and credit in every state and is the document most likely to be recognized abroad. Intention, in short, should be converted into the most durable legal form available, for the reasons that run through every chapter of this book. That principle applies equally to the other great category of disputes in assisted reproduction, which concerns not children but embryos. What an embryo is in law, and who may decide its fate, is the subject of the next two chapters. Chapter 6: Embryos as Property, Persons, or Something Between Somewhere between several hundred thousand and more than a million human embryos are thought to be in frozen storage in the United States. No one knows the number precisely, because no authority requires it to be reported. Most were created in the course of IVF treatment and not transferred because the patients had already had the children they wanted, or had stopped treatment, or had not yet decided what to do. Each is stored in a straw or vial in a tank of liquid nitrogen at a clinic or a long-term storage facility, and each is the subject of a consent form that the patients signed, often years ago. What those embryos are in law has become one of the most contested questions in American reproductive policy. The answer matters in several distinct settings: when a clinic negligently destroys embryos and the patients sue; when embryos are mixed up and a patient gives birth to someone else's child; when patients stop paying storage fees and cannot be reached; and, most dramatically, when a divorcing couple disagrees about what should happen to them, which is the subject of the next chapter. This chapter examines the underlying question of status and the litigation that turns on it. Three possible answers Courts and legislatures have considered three broad answers to the question of an embryo's legal status. The first is that an embryo is property. On this view, embryos belong to the people whose gametes created them, or who paid for their creation, and may be bought, sold, bailed, destroyed or bequeathed like other property, subject to regulation. The property view has the advantage of fitting comfortably into existing legal categories: a clinic that stores embryos is a bailee, a clinic that negligently destroys them is liable for the loss, and the patients' consent forms are contracts about the disposition of their property. Its disadvantage is that it seems to many people to fail to capture something important about embryos, which have the potential to become children. The second answer is that an embryo is a person, with the legal rights that personhood entails, including the right not to be destroyed. The personhood view reflects a moral and religious conviction, held by many, that human life begins at conception and deserves full protection from that point. Its legal consequences for IVF are far-reaching. If embryos are persons, then discarding surplus embryos may be homicide, freezing them may be unlawful confinement, and a clinic that destroys them negligently may be liable for wrongful death. IVF as generally practiced, which involves creating more embryos than will be transferred and sometimes testing and discarding embryos with genetic abnormalities, would be difficult to reconcile with a full personhood regime. The third answer, adopted by the Tennessee Supreme Court in Davis v. Davis in 1992 and followed by many courts since, is that an embryo is neither a person nor property but occupies an interim category that entitles it to special respect because of its potential for human life. The Davis court reasoned that the people who created the embryo have an interest in the nature of ownership, to the extent that they have decision-making authority over its disposition within the scope of policy set by law. The interim category is less a theory than a way of recognizing that neither of the two traditional categories fits. In practice, most American courts have treated embryos as something like special property: property for the purpose of deciding who controls them, but property of a special character that cannot be divided or allocated in the same way as ordinary assets. The Missouri Court of Appeals in McQueen v. Gadberry in 2016, for example, described frozen embryos as marital property of a special character, and awarded them jointly to both spouses, with no use permitted without both parties' consent. Louisiana: the personhood statute One state has adopted a statutory framework that treats embryos as persons for certain purposes. Louisiana's statute, enacted in 1986, declares that a human embryo fertilized in vitro is a juridical person that cannot be owned by the IVF patients or by the clinic, that may not be intentionally destroyed, and that may be relinquished for adoptive implantation. It provides that disputes about the embryo are to be resolved in the best interest of the embryo. The statute applies to embryos stored in Louisiana. Clinics in Louisiana have responded by shipping surplus embryos to storage facilities in other states, where the Louisiana statute does not apply. The Louisiana statute has produced little litigation directly, but it provided the legal foundation for an unusual lawsuit filed in Louisiana by a man seeking to prevent his former fiancée from destroying embryos the couple had created in California. The suit was brought in the names of the embryos themselves, as plaintiffs asserting a right to be born. It was dismissed, and a California court later enforced the couple's agreement barring either party from using the embryos without the other's consent. The episode illustrates both the aspirations of the personhood movement and the practical limits of a personhood statute in one state when the embryos and the governing agreement are located in another. Alabama: LePage and its aftermath In February 2024 the Alabama Supreme Court decided LePage v. Center for Reproductive Medicine, P.C., the most consequential judicial statement on embryo status in a generation. The facts were simple. Three couples had embryos stored at a fertility clinic in Mobile. In December 2020, a hospital patient entered the clinic's cryopreservation area through an unsecured doorway, removed several embryos from a storage tank, and dropped them, destroying them. The couples sued the clinic and the hospital, including claims under Alabama's Wrongful Death of a Minor Act. The trial court dismissed the wrongful death claims on the ground that an embryo outside the uterus is not a child or person within the meaning of the statute. The Alabama Supreme Court reversed. The majority held that the Wrongful Death of a Minor Act applies to all unborn children, regardless of their location, and that an embryo in storage is an unborn child for purposes of the statute. The court relied on its earlier decisions holding that the statute applies to unborn children in utero regardless of viability, and on a provision added to the Alabama Constitution in 2018 declaring that it is the public policy of the state to recognize and support the sanctity of unborn life and the rights of unborn children. The majority reasoned that nothing in the statute's text limited its application to children in utero. A concurring opinion by the Chief Justice discussed at length the theological basis for recognizing the value of unborn life. The decision had an immediate practical effect. Within days, several of Alabama's largest IVF providers, including the University of Alabama at Birmingham's health system, paused IVF treatments, fearing that they might be exposed to civil liability, and perhaps criminal liability, for the routine handling, testing or discarding of embryos. Patients with embryos in storage began to seek ways to move them out of the state. The public response was intense and crossed political lines, and in March 2024 the Alabama legislature enacted, and the governor signed, a statute granting civil and criminal immunity to providers and recipients of IVF services, and to manufacturers of goods used in IVF, for the damage to or death of an embryo, subject to certain exceptions. The immunity statute did not address the underlying question of an embryo's status; it simply shielded IVF providers from the consequences of the court's holding. Clinics resumed treatment. LePage left several matters open. It did not decide whether the discard of surplus embryos in accordance with patients' consent is lawful, or whether embryos are persons for purposes other than the wrongful death statute. The immunity statute left the plaintiffs in LePage and similar cases without the damages remedy the court had recognized, which raised questions about its application to pending cases and its consistency with the state constitution. And the decision prompted national debate about whether other states, particularly those with fetal personhood provisions in their constitutions or statutes, might reach similar conclusions. The national debate after Dobbs LePage came less than two years after Dobbs, and the two decisions are connected. Dobbs returned the regulation of abortion to the states, and many states have since enacted laws protecting unborn life from conception. Most of those statutes are directed at abortion and define their terms by reference to pregnancy, which means they do not apply to embryos outside the body. But some state laws define personhood or unborn child broadly, and the LePage reasoning, which relied on the text of a wrongful death statute and a constitutional statement of policy, could in principle be applied in states with similar provisions. The political response at the national level was swift. In 2024, Democrats in the Senate introduced legislation, called the Right to IVF Act, that would have established a federal statutory right to access assisted reproductive technology. It failed to advance, falling short of the votes needed to overcome a filibuster. Republican legislators introduced resolutions and bills expressing support for IVF. In 2025, as described in Chapter 1, the executive branch took steps aimed at lowering the cost of IVF. Several states enacted statutes protecting access to IVF or clarifying that embryos outside the body are not covered by their abortion or wrongful death laws. But no comprehensive federal statute has resolved the status question, and the question remains, as it has always been, one of state law. Negligence, lost embryos and mix-ups Even apart from the personhood question, clinics face significant liability when they lose, destroy or confuse embryos. Three kinds of cases are common. The first is equipment failure. In March 2018, on the same weekend, two storage tanks failed at fertility clinics in different parts of the country: one at the Pacific Fertility Center in San Francisco and one at University Hospitals in Cleveland. Thousands of eggs and embryos were affected. Litigation followed. In the San Francisco case, a federal jury in 2021 returned a verdict of about fifteen million dollars against the manufacturer of the failed tank in favor of a group of plaintiffs whose eggs and embryos had been destroyed. The Cleveland cases were largely settled. These cases proceeded on theories of product liability and negligence, and the damages turned on the value of what had been lost, which is where the status question returns: if embryos are property, damages may be limited to economic loss and the emotional distress recoverable for loss of property, whereas if they are persons, wrongful death damages may be available. The second is the destruction of embryos through negligent handling or storage. Courts in most states have rejected wrongful death claims for the loss of embryos. The Arizona Court of Appeals, in Jeter v. Mayo Clinic Arizona, decided in 2005, held that a cryopreserved embryo is not a person for purposes of Arizona's wrongful death statute, though it allowed other claims, including those based on negligent loss of property, to proceed. A Cook County, Illinois, trial judge in 2005 allowed a wrongful death claim for the loss of an embryo to proceed, but that approach attracted little support elsewhere. LePage is the exception, not the rule. In most states, patients whose embryos are lost must proceed on theories of negligence, breach of contract, or bailment, and damages for emotional distress are limited by the rules governing those theories. The third is the embryo mix-up, in which a patient receives the wrong embryo and gives birth to a child not genetically related to her or her partner. These cases are rare but devastating. In a widely reported case filed in California in 2019, two couples discovered that each had given birth to the other's child after an embryo mix-up at a clinic, and the babies were exchanged. In a lawsuit filed in Georgia in 2025, a woman who had given birth after IVF, and who learned through genetic testing that the child was not related to her, sued the clinic; by then she had given up custody of the child to its genetic parents. Her case highlighted a question that the law has not resolved consistently: when a mix-up occurs, who is the legal parent, the woman who gave birth or the people whose embryo was used? Most states' parentage statutes do not answer this directly. Courts have generally resolved such cases by identifying the genetic parents as the parents, often through the parties' agreement, but the gestational mother's claim is not negligible, particularly under statutes that make giving birth a basis of maternity. The claims against clinics in these cases typically sound in negligence, breach of contract, and infliction of emotional distress. Embryo donation and "embryo adoption" For patients who have finished building their families, one option for surplus embryos is to donate them to another patient or couple. Legally, embryo donation sits uneasily between the categories discussed at the start of this chapter. Most states treat it as a transfer of control over property, accomplished by contract: the donors relinquish all rights and responsibilities, and the recipients assume them. Under the Uniform Parentage Act and similar statutes, the donors are not parents of any resulting child, and the woman who gives birth and her consenting spouse or partner are. No court proceeding is required, and the arrangement resembles gamete donation more than adoption. Some agencies, however, describe the process as "embryo adoption" and structure it to mirror adoption, with home studies of the recipients, matching of donors and recipients, and sometimes ongoing contact. The terminology is deliberate: organizations that regard embryos as persons prefer to frame the transfer as the placement of a child rather than the transfer of property. A few states have enacted statutes that provide for a court proceeding resembling adoption before or after the birth of a child from a donated embryo, and Louisiana, as noted above, provides for relinquishment for "adoptive implantation." For most families the practical consequences of the terminology are modest, but the framing matters to the wider debate: a legal system that routinely described embryo donation as adoption would be one step closer to treating embryos as children. Embryo donation raises its own drafting questions. The donation agreement should address whether the donors and recipients will exchange identifying information, whether the resulting children will be told of their origins and permitted to contact genetic siblings in the donor family, what happens to any embryos the recipients do not use, and whether the donors retain any say over their further disposition. Recipients should confirm that the donors have validly relinquished all rights and that the clinic's records establish the chain of consent, because a donor who later claims not to have agreed may otherwise be able to cloud the recipients' parentage. Abandoned embryos A quieter but more widespread problem is the embryo whose owners have stopped paying for storage and cannot be reached. Clinics are reluctant to discard such embryos without clear authority, and many store them indefinitely at their own expense. The consent forms that patients sign usually address this situation, providing that the clinic may discard or otherwise dispose of the embryos if storage fees are not paid for a specified period after written notice. ASRM's ethics committee has taken the position that clinics may treat embryos as abandoned after a reasonable period without contact and after diligent efforts to reach the patients, if the consent forms so provide and the clinic has a written policy. Statutes addressing abandoned embryos are rare, although a few states have addressed related questions, and the risk of disputes remains, particularly because patients who stopped paying may later reappear and assert that they never intended to abandon their embryos. The lesson of these cases is the same as that of the preceding chapters. The status of embryos is unsettled, and in some states politically volatile, but the practical allocation of control over them rests in most places on the documents the patients signed. Those documents are about to acquire their greatest importance in the setting of divorce, where two people who once agreed about their embryos no longer do. Chapter 7: Frozen Embryos in Divorce The frozen embryo dispute is the purest test of the law's commitment to intention, because it pits two intentions against each other. At the time the embryos were created, both spouses intended to have children together. At the time of the divorce, one spouse wants to use the embryos, or to donate them to another couple, and the other wants them destroyed or kept frozen indefinitely. Both intentions are genuine. The court must decide which prevails, and whatever it decides, someone will either become a genetic parent against his or her will or lose what may be the last chance of having a genetic child. American courts have developed three approaches to these disputes. They are usually called the contractual approach, the balancing approach, and the contemporaneous mutual consent approach. In practice many courts combine them, typically by enforcing a clear prior agreement if there is one and balancing the parties' interests if there is not. This chapter explains each approach through the cases that defined it, the statutory intervention in Arizona, the comparative experience, and what couples and their lawyers can do to avoid the dispute altogether. Davis v. Davis: the foundation The first appellate decision on the question, and still the most influential, is Davis v. Davis, decided by the Tennessee Supreme Court in 1992. Junior Lewis Davis and Mary Sue Davis had undergone several unsuccessful IVF cycles, and seven embryos remained in storage when they divorced. They had signed no agreement about what should happen to the embryos in the event of divorce. At trial Mary Sue sought the embryos to have children herself; by the time the case reached the Tennessee Supreme Court she had remarried and wanted instead to donate them to another couple. Junior Davis opposed both, not wanting to become a genetic father against his will, in part because of his own childhood experience of separation from his parents. The court began by rejecting both the personhood and property characterizations of embryos, placing them instead in the interim category entitled to special respect described in Chapter 6. It then laid down a framework that has shaped the field ever since. First, the preferences of the progenitors should be given effect. Second, if their preferences cannot be ascertained or they disagree, any prior agreement between them should be enforced. Third, if there is no prior agreement, the court must weigh the relative interests of the parties in using or not using the embryos. The court added that ordinarily the party wishing to avoid procreation should prevail, provided that the other party has a reasonable possibility of achieving parenthood by means other than use of the embryos in question. If no other reasonable alternatives exist, the argument in favor of using the embryos should be considered. And if the party seeking control intends merely to donate the embryos to another couple, the objecting party obviously has the greater interest and should prevail. Applying that framework, the court held that Junior Davis's interest in avoiding unwanted parenthood outweighed Mary Sue's interest in donating the embryos. Davis thus established both the contractual approach, as the primary rule, and the balancing approach, as the fallback, and it articulated the presumption in favor of the party who does not want to procreate that most balancing courts have followed. The contractual approach Under the contractual approach, courts enforce agreements the parties made, usually in the clinic's consent forms, about the disposition of embryos in the event of divorce. The leading case is Kass v. Kass, decided by the New York Court of Appeals in 1998. Maureen and Steven Kass had signed consent forms providing that if they could not agree on disposition, the embryos would be donated to the IVF program for research. When they divorced, Maureen sought the embryos to have a child. The court held that agreements between progenitors regarding disposition of their embryos should generally be presumed valid and binding and enforced in any dispute between them. Such agreements, the court reasoned, minimize misunderstanding, maximize procreative liberty by reserving to the progenitors the authority to make what is a deeply personal decision, and provide the certainty that clinics need. The form clearly expressed the parties' intention that the embryos be donated to research if they could not agree, and the court enforced it. Many courts have followed Kass. The Texas Court of Appeals in Roman v. Roman in 2006 enforced an agreement providing that the embryos would be discarded upon divorce, reversing a trial court that had awarded them to the wife. The Oregon Court of Appeals in In re Marriage of Dahl and Angle in 2008 enforced an agreement giving the wife the right to decide the embryos' fate, and she chose destruction. A California trial court in Findley v. Lee in 2015 enforced a consent form providing that embryos would be discarded upon divorce, even though the wife, who had been diagnosed with cancer before the embryos were created, argued that they were her only realistic chance of having a genetic child. The Arizona Supreme Court in Terrell v. Torres in 2020 enforced an agreement that it read to require donation of the embryos to another couple, rejecting the wife's argument, which the intermediate appellate court had accepted on a balancing analysis, that she should be allowed to use them because her cancer treatment had left her unable to produce more eggs. The Connecticut Supreme Court in Bilbao v. Goodwin in 2019 enforced a storage agreement providing that the embryos would be discarded in the event of divorce. The contractual approach has obvious virtues. It respects the parties' own choices, it is predictable, and it encourages couples to think about the question in advance. Its weaknesses are equally obvious. Consent forms are drafted by clinics, often presented as part of a stack of documents at an emotionally charged time, and frequently signed without legal advice. The options they offer are chosen by the clinic, not negotiated by the parties. Some forms are ambiguous about whether they apply to divorce at all, as opposed to death or abandonment. And people's circumstances and views change over years in ways they may not have anticipated when they signed. Limits on enforcement For those reasons, some courts have declined to enforce agreements that would compel one party to become a genetic parent against his or her current wishes. The Massachusetts Supreme Judicial Court was the first to take that position. In A.Z. v. B.Z., decided in 2000, the husband had signed a series of consent forms, several of them blank at the time of his signature and later filled in by his wife, providing that the embryos would be given to the wife for implantation if the couple separated. The court declined to enforce the forms, both because they did not clearly reflect the husband's intention to apply them to divorce years later, and because, as a matter of public policy, it would not enforce an agreement that would compel one donor to become a parent against his or her will. The court stated that prior agreements to enter into familial relationships should not be enforced against individuals who later reconsider their decisions. The New Jersey Supreme Court in J.B. v. M.B., decided in 2001, adopted a middle course. It held that agreements about embryo disposition are enforceable, subject to the right of either party to change his or her mind about disposition up to the point of use or destruction. If a party does change his or her mind and the parties then disagree, the court will weigh their interests, and ordinarily the party choosing not to become a biological parent will prevail. The court was concerned, like the Massachusetts court, with the public policy against forcing parenthood on an unwilling person, and it noted that the wife in that case did not seek to use the embryos herself but wished them destroyed, while the husband wanted to use or donate them. The Washington Supreme Court in Litowitz v. Litowitz, decided in 2002, resolved a dispute over embryos created with the husband's sperm and donor eggs by reference to the couple's agreement with the clinic, and held that the wife, who had no genetic connection to the embryos, could not rely on a claim of parental rights. The case shows how the contractual approach can decide disputes on grounds that seem at first to have little to do with procreation, and how the genetic composition of the embryos may shape the parties' positions. The balancing approach When there is no enforceable agreement, most courts balance the parties' interests. The leading recent cases have developed that balancing in some detail. The Pennsylvania Superior Court in Reber v. Reiss, decided in 2012, awarded embryos to a wife who had undergone IVF before treatment for breast cancer. The court found that the embryos were likely her only opportunity to have a biological child, that the husband's objections were outweighed by that interest, and that the husband, who already had a child with another partner since the divorce, would not suffer the same deprivation. The Illinois Appellate Court in Szafranski v. Dunston first considered the question in 2013. Karla Dunston had been diagnosed with lymphoma and, before undergoing chemotherapy that would likely leave her infertile, created embryos with her then-boyfriend, Jacob Szafranski. After they separated, he sought to prevent her from using them. The court held that the dispute should be resolved first by any agreement between the parties, and only if there was none by balancing their interests. On remand, the trial court found that Szafranski had orally agreed to help Dunston have a child, and in any event that the balance of interests favored Dunston, for whom the embryos were her only chance of genetic parenthood. The appellate court affirmed in 2015. The Colorado Supreme Court in In re Marriage of Rooks, decided in 2018, provided the most detailed balancing framework to date. The court held that trial courts should first look for an agreement, and if there is none, should balance the parties' respective interests. It listed factors to consider, including the intended use of the embryos by the party seeking to preserve them, whether that party can achieve genetic parenthood by other reasonable means, the parties' original reasons for undergoing IVF, the hardship to the party seeking to avoid becoming a genetic parent, any bad faith attempt to use the embryos as leverage in the divorce, and other considerations relevant to the circumstances. The court cautioned trial courts against giving weight to certain considerations, such as whether the party seeking to become a parent could afford another child or could adopt, and it stated that the number of the parties' existing children should not by itself decide the case. The court reversed a decision that had awarded the embryos to the husband, and remanded for balancing under the proper standard. The balancing approach allows courts to consider the particular circumstances of the parties, and it has produced results that most observers find just in cases like Reber and Szafranski, where the party seeking the embryos had no other realistic path to genetic parenthood. Its weakness is that it gives courts wide discretion, and different courts balance similar interests differently. The contemporaneous mutual consent approach The Iowa Supreme Court, in In re Marriage of Witten in 2003, adopted a third approach. The court held that no transfer, release, disposition or use of embryos can occur without the signed authorization of both donors, at the time the action is to be taken. If the parties cannot agree, the status quo is maintained: the embryos remain in storage, at the expense of the party opposing destruction. The court was troubled by the idea of enforcing prior agreements about decisions as personal as procreation, but was equally reluctant to have courts substitute their judgment for that of the parties through balancing. The mutual consent approach has been criticized for failing to resolve anything. In practice it gives each party a veto and leaves the embryos in storage indefinitely, which is often what the party opposing use wants. It has been adopted by few courts, though its emphasis on current consent resonates with the Massachusetts and New Jersey concern with forced procreation. Comparing the approaches The three approaches differ in what they treat as decisive and in the kinds of results they produce, as Table 3 sets out. Table 3. The three judicial approaches to frozen embryo disputes in divorce. Approach What decides the dispute Leading cases Typical result Contractual Prior agreement, usually clinic consent form Kass v. Kass (N.Y. 1998); Roman v. Roman (Tex. App. 2006); Terrell v. Torres (Ariz. 2020) Agreement enforced even against a party seeking use Balancing Weighing of parties' interests, with presumption against forced procreation Davis v. Davis (Tenn. 1992); Reber v. Reiss (Pa. Super. 2012); In re Marriage of Rooks (Colo. 2018) Objecting party usually prevails unless embryos are the other's only chance Contemporaneous mutual consent Current agreement of both parties; otherwise status quo In re Marriage of Witten (Iowa 2003) Embryos stay frozen indefinitely Most jurisdictions in practice apply a hybrid: they enforce a clear, unambiguous agreement that specifically addresses divorce, and if there is none, they balance, typically with a presumption in favor of the party opposing procreation. Massachusetts and New Jersey add a public policy limit on agreements compelling parenthood. Arizona's statutory intervention Arizona is the only state to have enacted a statute prescribing the outcome of embryo disputes in divorce. The statute, enacted in 2018, directs courts in a dissolution proceeding to award embryos to the spouse who intends to allow them to develop to birth, regardless of any prior agreement. It further provides that a spouse who did not consent to be a parent is not a legal parent of any resulting child and has no parental rights or support obligations. The statute is sometimes described as a pro-life measure, because it favors development over destruction, and it reverses the ordinary presumption in favor of the party opposing procreation. Its application to embryos created before its effective date was addressed in Terrell v. Torres, where the Arizona Supreme Court decided the case under the parties' agreement because the statute did not apply retroactively. The statute raises constitutional questions about compelled genetic parenthood that no court has yet fully resolved. It also illustrates a trend: the more politically salient embryo status becomes, the more likely legislatures are to intervene in what had been a matter of private agreement and judicial balancing. Comparative notes Courts in other countries have faced the same dilemma. In Evans v. United Kingdom, decided by the Grand Chamber of the European Court of Human Rights in 2007, Natallie Evans had created embryos with her fiancé before undergoing treatment for ovarian cancer that left her unable to produce eggs. After they separated, he withdrew his consent to their use, which under the Human Fertilisation and Embryology Act 1990 required their destruction. The Court held that the statute's requirement of continuing consent from both gamete providers did not violate her right to respect for private and family life, emphasizing that the rule was a clear, bright-line policy adopted after extensive public debate. In Israel, by contrast, the Supreme Court in the Nachmani case in 1996 permitted a woman to use embryos over her estranged husband's objection, reasoning that her interest in parenthood outweighed his interest in avoiding it in the circumstances of that case. Avoiding the dispute The practical lesson of these cases is that the most important protection is a carefully considered, specific agreement, made at the time the embryos are created, and revisited periodically. Clinic consent forms are a start, but they are rarely adequate on their own. Couples undergoing IVF, especially those with embryos that may represent one partner's last chance at genetic parenthood, should consider a separate agreement drafted with independent counsel for each party, specifically addressing divorce, separation, death, incapacity and abandonment; specifying which party, if any, may use the embryos and on what terms, including whether the other will be a legal parent; addressing donation and research; and providing for periodic reaffirmation. Couples should also consider whether their prenuptial or postnuptial agreement should address embryos, though an embryo agreement signed in the context of a divorce negotiation, rather than at the time of creation, is more vulnerable to challenge on grounds of duress. Even a careful agreement will not protect against every outcome. In states that follow A.Z. v. B.Z. or J.B. v. M.B., an agreement compelling procreation may be unenforceable whatever its terms. In Arizona, the statute overrides the agreement. And if the parties move, the court that decides their divorce may apply its own law. The agreement nevertheless remains the best available evidence of intention, and as the case law shows, it is enforced far more often than not. As with surrogacy and parentage, intention protects people only when it has been captured carefully and in advance. Chapter 8: Crossing Borders: International Surrogacy and Portability Every problem discussed so far in this book becomes harder when a family crosses a national border. Within the United States, the Full Faith and Credit Clause guarantees that a judgment of parentage entered in one state will be recognized in all the others. No equivalent guarantee exists between nations. A child born in California through surrogacy to intended parents from Spain may have two legal parents under California law and none under Spanish law. A child born in Ukraine to American intended parents may be recognized as theirs under Ukrainian law and still face hurdles in obtaining a US passport. The gap between intention and legal status, which American law has done so much to close within its own borders, reopens at the frontier. This chapter examines the two main directions of international surrogacy: foreign intended parents who come to the United States, and American intended parents who go abroad. It then considers the international human rights law that has developed in response, and the prospects for international agreement. Foreign intended parents in the United States The United States is one of the world's leading destinations for international surrogacy. Intended parents come from countries where surrogacy is prohibited, such as France, Germany, Spain and Italy; from countries where it is permitted only in uncompensated forms that are hard to arrange, such as the United Kingdom, Canada and Australia; and from countries that restrict it to heterosexual married couples, which excludes same-sex couples and single people. They come to the United States because several states, notably California, permit compensated gestational surrogacy for anyone, regardless of nationality, marital status or sexual orientation, and provide a reliable judicial route to parentage. For these families, the American side of the process is typically straightforward. The surrogacy agreement is drafted under the law of the carrier's state, a pre-birth order is entered naming the intended parents as the child's parents, and the child's birth certificate lists them. The child, born on US soil, has historically been a US citizen at birth under the Citizenship Clause of the Fourteenth Amendment, and can therefore obtain a US passport and travel home with the parents. The difficulty arises when the family gets home. The intended parents' home country may refuse to recognize the American judgment or birth certificate, on the ground that recognizing parentage established through surrogacy would violate its public policy. In that case the child may have no legal parent in the home country, or only the genetic father, who can usually establish paternity through ordinary procedures. The intended mother, or the non-genetic father in a male couple, may be a legal stranger to the child. The consequences can be serious. The child may be unable to obtain citizenship in the home country, may lack inheritance rights, and may be left without a legal parent if the genetic parent dies or the couple separates. Some countries have developed routes to fill the gap, such as adoption by the non-genetic intended parent after the child arrives. Others have been more resistant. A newer uncertainty concerns citizenship at birth. In January 2025 the President issued an executive order directing federal agencies not to recognize as citizens children born in the United States whose mothers were unlawfully present or present only temporarily, and whose fathers were not citizens or lawful permanent residents. The order was challenged immediately and blocked by lower courts, and the litigation over its validity reached the Supreme Court. The order, if it took effect in some form, would raise novel questions for international surrogacy, including which person counts as the "mother" for purposes of the order when a child is born to an American gestational carrier for foreign intended parents. Anyone planning an arrangement of this kind must confirm the current state of the law and the relevant agency guidance before relying on the child's acquiring US citizenship at birth. American intended parents abroad American intended parents also travel abroad for surrogacy, principally because it is less expensive than surrogacy in the United States. The destinations have shifted repeatedly over the past two decades, as countries that opened to international surrogacy closed again in response to scandals or political pressure. India was a major destination until it restricted international surrogacy in the mid-2010s and then, in the Surrogacy (Regulation) Act 2021, confined surrogacy to altruistic arrangements for Indian couples and certain Indian women, excluding foreign nationals. Thailand, Nepal and Cambodia each closed to foreigners after controversies. Ukraine became a significant destination, because its Family Code provides that when an embryo created by a married couple is transferred to a gestational carrier, the couple are the child's parents, and the carrier has no parental rights. The Russian invasion of 2022 disrupted Ukrainian surrogacy and left some families and carriers in dangerous circumstances. Other destinations have emerged, including countries in Latin America and Central Asia, but the legal protections for carriers, children and intended parents in many of them are uncertain. For American intended parents who use surrogacy abroad, the main legal question is how to bring the child home as a US citizen. A child born abroad acquires US citizenship at birth only through a US citizen parent, under the Immigration and Nationality Act. Chapter 5 described the State Department's 2021 policy under which a child born abroad to married parents, at least one of whom is a citizen, is treated as born in wedlock if the child is biologically related to at least one of the parents. But the statute still requires a biological connection of some kind, genetic or gestational, between the child and at least one parent for the purpose of transmission of citizenship, and the State Department may require DNA evidence of that connection. Where the embryo was created with donor egg and donor sperm, the child may have no biological connection to either intended parent and cannot acquire citizenship at birth through them; the family would need to pursue an immigrant visa for the child on the basis of an adoption recognized for immigration purposes, which is a lengthy and uncertain process. The home state's recognition of the foreign parentage is a separate question. A foreign birth certificate or court order naming the intended parents may be recognized by American courts under principles of comity, but comity is discretionary. Many practitioners advise American intended parents who use surrogacy abroad to obtain a judgment of parentage or an adoption in their home state after returning, for the same reasons that Chapter 4 recommends a judgment for domestic families. Human rights law and the child's identity The difficulties faced by children born through international surrogacy have prompted a body of human rights law in Europe that, while not binding in the United States, illuminates the underlying issue and affects the families who come to the United States from Europe. The leading case is Mennesson v. France, decided by the European Court of Human Rights in 2014. A French couple had twins through gestational surrogacy in California, using the husband's sperm and donor eggs. California courts declared them the legal parents, but French authorities refused to transcribe the California birth certificates into the French civil register, on the ground that surrogacy was contrary to French public policy. The European Court held that France had not violated the parents' right to respect for family life, because the family was in practice able to live together in France. But it held that France had violated the children's right to respect for their private life, which includes the right to establish the substance of one's identity, including one's legal parent-child relationship. The court placed particular weight on the fact that the intended father was the children's biological father, and held that France could not deny recognition of that relationship. In 2019, in its first advisory opinion under a new protocol permitting national courts to request guidance, the European Court addressed the position of the intended mother. It advised that the right to respect for private life requires that domestic law provide a means of recognizing the legal relationship between the child and the intended mother, but that states have discretion about the means, and that adoption may suffice if it can be carried out promptly and effectively in the child's best interests. In Paradiso and Campanelli v. Italy, decided by the Grand Chamber in 2017, the court reached a different result on different facts. An Italian couple had brought a child born through surrogacy in Russia to Italy; the child turned out to have no genetic connection to either of them. Italian authorities removed the child and placed him for adoption. The Grand Chamber held that Italy had not violated the couple's rights, because they had no biological tie to the child and had lived with him only briefly, so no family life in the protected sense had developed. The case underlines the importance of the genetic link in European law. The European Union's Court of Justice has also addressed a related question. In V.M.A. v. Stolichna obshtina in 2021, a child born in Spain to two mothers, one Bulgarian, had a Spanish birth certificate naming both. Bulgaria refused to issue a birth certificate naming both mothers. The Court held that Bulgaria must issue the child an identity document and must recognize the parent-child relationship with both mothers for the purpose of the child's exercise of free movement rights under EU law, though not necessarily for all purposes of Bulgarian domestic law. Some European countries have moved in the opposite direction. In 2024 Italy, which already prohibited surrogacy within its borders, enacted a law extending that prohibition to Italian citizens who undertake surrogacy abroad, making it a crime punishable in Italy even when the arrangement is lawful where it takes place. The practical effect on Italian families who have used surrogacy in the United States, and on their children's recognition in Italy, remains to be seen. Comparing national approaches National approaches to surrogacy vary widely, and the variation determines where intended parents go and what problems they face when they return. Table 4 summarizes the position in several countries that feature frequently in international surrogacy. Table 4. Selected national approaches to surrogacy. Country Compensated surrogacy Legal parentage at birth Notes United States (most states) Permitted Intended parents, often by pre-birth order Open to foreign intended parents; varies by state United Kingdom Prohibited; reasonable expenses only Carrier is mother; parental order after birth Law Commission recommended reform in 2023 Canada Prohibited; reimbursement of expenses Varies by province Federal Assisted Human Reproduction Act 2004 India Prohibited; altruistic only Intended parents under statute Surrogacy (Regulation) Act 2021; foreigners excluded Italy Prohibited, including abroad for citizens since 2024 No recognition of intended mother without adoption Criminal penalties Ukraine Permitted Intended parents (married heterosexual couples) Disrupted by the war since 2022 The United Kingdom's position deserves particular mention, because it contrasts so sharply with the American one. Under the Surrogacy Arrangements Act 1985, commercial surrogacy arrangements and advertising are prohibited, though the carrier may be paid reasonable expenses. The carrier is the child's legal mother at birth, and if she is married, her spouse is generally the other legal parent. The intended parents may apply for a parental order under the Human Fertilisation and Embryology Act 2008 after the birth, if at least one of them is genetically related to the child and the carrier consents. The system gives the carrier the right to change her mind after birth, which is the opposite of the American approach. The Law Commission of England and Wales and the Scottish Law Commission recommended in 2023 a new pathway under which intended parents could be legal parents from birth, subject to safeguards and to the carrier's right to object within a short period after birth. Those recommendations have not been enacted. Canada similarly prohibits payment to carriers beyond reimbursement of expenses under its Assisted Human Reproduction Act 2004, but parentage is governed by provincial law, and several provinces have adopted procedures that allow intended parents to be recognized without adoption. The prospects for international agreement The Hague Conference on Private International Law has been studying the legal parentage of children, including children born through international surrogacy, for more than a decade. An experts' group examined the feasibility of a convention on the recognition of foreign judgments on legal parentage, and a protocol dealing specifically with judgments arising from international surrogacy agreements. Its work has confirmed that a binding instrument is technically feasible but has struggled with the fundamental disagreement among states about whether surrogacy should be permitted at all. A convention modeled on the Hague Adoption Convention, which establishes safeguards for intercountry adoption and requires recognition of adoptions made in accordance with it, has been proposed as a model. But progress has been slow, and there is no near-term prospect of an instrument that would guarantee recognition. In the meantime, families who cross borders must do what families who cross state lines within the United States have long done: secure the strongest possible legal documentation in each relevant jurisdiction. For foreign intended parents who come to the United States, that means understanding before they begin what their home country will recognize, and planning for any additional proceedings, such as adoption, that will be required on their return. For American intended parents who go abroad, it means ensuring that at least one intended parent has a biological connection to the child, obtaining the foreign parentage documentation, and securing a judgment or adoption at home. For both, it means that the law of the place where the child is born is only the beginning of the analysis. Conclusion: Intention, Captured in Time The history traced in this book runs from a courtroom in New Jersey in 1988, where a judge treated a surrogacy contract as a bargain for a baby and set it aside, to the routine pre-birth judgments of the present, in which courts declare the parentage of children not yet born on the strength of documents signed before they were conceived. Across surrogacy, parentage and embryo disputes, the law has come to accept that the people who deliberately set out to create a child, and who recorded that purpose in advance, should be treated as that child's parents and should decide what becomes of the embryos they created. That is a remarkable shift, and in most of the United States it is now settled law. But the preceding chapters also show why the shift is incomplete, and why it cannot be complete in the sense of making intention simply sufficient. Intention is a mental state. The law can act only on evidence of it, and it demands that evidence in particular forms: a compliant surrogacy agreement signed before any medical procedure, a consent to assisted reproduction, a judgment, a disposition agreement. Each form is valid in some places and not others, for some purposes and not others. The families who come to grief are rarely those whose intentions were unclear. They are those whose intentions were never converted into a form that the relevant court or official was obliged to honor. What follows for families Several practical conclusions follow from that observation, and they apply whether the family is formed through surrogacy, donor gametes or IVF alone. First, the choice of place is a legal choice. For surrogacy, the state where the carrier lives and the child will be born determines whether the agreement is enforceable and how parentage will be established. For embryos, the state where the couple lives when they divorce determines which of the three approaches described in Chapter 7 will be applied. For international families, the home country's law determines whether an American judgment will be recognized at all. These choices are often made by default, by an agency's match or a clinic's location, and they should be made deliberately. Second, the documents should be drafted for the worst case, not the expected one. A surrogacy agreement that addresses reduction, the death of an intended parent and the intended parents' divorce may seem morbid to parties who are optimistic and trusting at the outset, but these are the situations in which the agreement will actually be read by a court. An embryo disposition agreement that clearly addresses divorce, and that each party has reviewed with independent counsel, is far more likely to be enforced than a clinic form with a checked box. Third, a judgment is worth the trouble. Chapter 4 explained why a judgment of parentage or adoption is the only form of parentage guaranteed full faith and credit throughout the United States and the form most likely to be recognized abroad. For same-sex couples, for unmarried couples, for families using known donors, for families who may move or travel internationally, and for families formed through surrogacy, the cost of obtaining a judgment is small compared with the cost of discovering, in a crisis, that parentage resting on a presumption or a birth certificate is not recognized. Fourth, documents should be revisited. People's circumstances change: they marry, separate, have children, become ill, move. Embryo disposition agreements in particular should be reaffirmed or revised periodically, so that the document that eventually governs reflects the parties' considered views rather than an assumption made years earlier in a clinic waiting room. What remains unsettled The law's commitment to intention coexists with several unresolved questions, and honesty requires acknowledging them. The most significant is the status of the embryo. LePage showed that a single state supreme court decision, interpreting an ordinary wrongful death statute in light of a constitutional declaration of policy, could suspend IVF in an entire state within days. The Alabama legislature's immunity statute restored treatment without resolving the underlying question, and the debate over fetal personhood continues in state legislatures and courts after Dobbs. If more states adopt the view that embryos are persons, the contractual framework on which embryo disposition rests could be displaced, and the routine practices of IVF, including the creation, freezing, testing and discarding of surplus embryos, could face legal challenge. The intention-based model of embryo control assumes that the progenitors have authority over their embryos. A personhood model denies it. A second unsettled question concerns the durability of the constitutional protection for same-sex families. Obergefell and Pavan established that married same-sex couples must be treated equally in the application of parentage presumptions. That protection is intact, and the Supreme Court has so far declined invitations to revisit Obergefell. But the protection depends on the continued vitality of a line of substantive due process decisions that some members of the Court have questioned, and it does not extend to unmarried couples or to the details of state surrogacy law. The practical recommendation of judgments for same-sex families is as sound today as it was before 2015. A third concerns the tension between the carrier's autonomy and the intended parents' interest in the pregnancy. Modern statutes resolve that tension decisively in favor of the carrier's right to make her own medical decisions, and no American court would order her to undergo or refuse a procedure. But the post-Dobbs variation in state abortion law means that the carrier's practical options may depend on where she lives, and surrogacy agreements must now address questions of travel and access that were largely hypothetical before 2022. A fourth concerns international recognition. The European human rights cases have established that children have a right to recognition of their relationship with at least a genetic parent, and a means of recognition with an intended parent, but they leave states wide discretion, and some states are moving toward greater restriction, as Italy's 2024 law shows. The Hague Conference's work has not yet produced a binding instrument. And questions about the citizenship of children born in the United States to foreign intended parents have added a new layer of uncertainty. A final word The law of assisted reproduction is sometimes described as a law of strangers: of donors, carriers, clinics and courts, all involved in the creation of a family but none of them the family itself. That description misses the point. The people at the center of this law are intended parents who want a child, carriers who help them, and children who need to know who their parents are. The law's increasing reliance on intention is a way of honoring what those people meant to do. The task for families and their lawyers is to ensure that what they meant is recorded, in the right form and in the right place, before anyone needs to prove it. Notes Introduction 1. In re Baby M, 109 N.J. 396, 537 A.2d 1227 (1988). 1. Centers for Disease Control and Prevention, National Assisted Reproductive Technology Surveillance System, annual ART Fertility Clinic and National Summary reports. Chapter 1 1. Current Good Tissue Practice and donor eligibility requirements, 21 C.F.R. Part 1271. 1. Fertility Clinic Success Rate and Certification Act of 1992, 42 U.S.C. §§ 263a-1 to 263a-7. 2. Executive Order, "Expanding Access to In Vitro Fertilization" (Feb. 18, 2025). 3. Johnson v. Calvert, 5 Cal. 4th 84, 851 P.2d 776 (1993). 4. In re Marriage of Buzzanca, 61 Cal. App. 4th 1410 (1998). 5. Uniform Law Commission, Uniform Parentage Act (2002) and Uniform Parentage Act (2017), with official comments. Chapter 2 1. In re Baby M, 109 N.J. 396 (1988). 1. Illinois Gestational Surrogacy Act, 750 ILCS 47. 2. Texas Family Code, chapter 160, subchapter I (gestational agreements). 3. J.F. v. D.B., 116 Ohio St. 3d 363, 2007-Ohio-6750. 4. Rosecky v. Schissel, 2013 WI 66. 5. In re Baby, 447 S.W.3d 807 (Tenn. 2014). 6. P.M. v. T.B., 907 N.W.2d 522 (Iowa 2018). 7. New York Child-Parent Security Act, N.Y. Family Court Act art. 5-C (effective Feb. 15, 2021). 8. Michigan Assisted Reproduction and Surrogacy Parentage Act, 2024 Mich. Pub. Acts (effective April 2025), repealing the Surrogate Parenting Act of 1988. 9. In re Gestational Agreement, 2019 UT 40. 10. Louisiana Revised Statutes 9:2718 to 9:2720.15 (gestational carrier contracts). 11. Soos v. Superior Court, 182 Ariz. 470 (Ct. App. 1994); Arizona Revised Statutes § 25-218. 12. Indiana Code § 31-20-1-1; Nebraska Revised Statutes § 25-21,200. Chapter 3 1. Uniform Parentage Act (2017), article 8 (surrogacy agreements). 1. Practice Committee of the American Society for Reproductive Medicine and Practice Committee of the Society for Assisted Reproductive Technology, "Recommendations for practices using gestational carriers: a committee opinion," Fertility and Sterility (2022). 2. C.M. v. M.C., 7 Cal. App. 5th 1188 (2017). 3. Dobbs v. Jackson Women's Health Organization, 597 U.S. 215 (2022). 4. California Family Code § 7962. Chapter 4 1. 42 U.S.C. § 666(a)(5) (voluntary acknowledgment of paternity; full faith and credit). 1. In re T.J.S., 212 N.J. 334, 54 A.3d 263 (2012). 2. New Jersey Gestational Carrier Agreement Act, N.J.S.A. 9:17-60 et seq. (2018). 3. V.L. v. E.L., 577 U.S. 404 (2016) (per curiam). 4. Massachusetts Parentage Act, St. 2024 (effective Jan. 31, 2025). 5. Woodward v. Commissioner of Social Security, 435 Mass. 536 (2002). 6. Astrue v. Capato, 566 U.S. 541 (2012). Chapter 5 1. Elisa B. v. Superior Court, 37 Cal. 4th 108 (2005). 1. K.M. v. E.G., 37 Cal. 4th 130 (2005). 2. Alison D. v. Virginia M., 77 N.Y.2d 651 (1991). 3. Brooke S.B. v. Elizabeth A.C.C., 28 N.Y.3d 1 (2016). 4. Obergefell v. Hodges, 576 U.S. 644 (2015). 5. Pavan v. Smith, 582 U.S. 563 (2017) (per curiam). 6. McLaughlin v. Jones, 243 Ariz. 29 (2017). 7. Henderson v. Box, 947 F.3d 482 (7th Cir. 2020). 8. Partanen v. Gallagher, 475 Mass. 632 (2016). 9. Respect for Marriage Act, Pub. L. No. 117-228 (2022). 10. Jhordan C. v. Mary K., 179 Cal. App. 3d 386 (1986). 11. In re K.M.H., 285 Kan. 53 (2007). 12. Kiviti v. Pompeo (D. Md. 2020). 13. U.S. Department of State, announcement on interpretation of "born in wedlock" for children born through assisted reproductive technology (May 18, 2021). Chapter 6 1. Davis v. Davis, 842 S.W.2d 588 (Tenn. 1992). 1. McQueen v. Gadberry, 507 S.W.3d 127 (Mo. Ct. App. 2016). 2. Louisiana Revised Statutes 9:121 to 9:133. 3. LePage v. Center for Reproductive Medicine, P.C., Nos. SC-2022-0515 and SC-2022-0579 (Ala. Feb. 16, 2024). 4. Alabama Constitution, art. I, § 36.06 (2018 amendment). 5. Alabama Senate Bill 159 (2024) (immunity for providers of in vitro fertilization services). 6. Jeter v. Mayo Clinic Arizona, 211 Ariz. 386, 121 P.3d 1256 (Ct. App. 2005). 7. Ethics Committee of the American Society for Reproductive Medicine, "Disposition of unclaimed embryos: an Ethics Committee opinion," Fertility and Sterility. Chapter 7 1. Davis v. Davis, 842 S.W.2d 588 (Tenn. 1992). 1. Kass v. Kass, 91 N.Y.2d 554, 696 N.E.2d 174 (1998). 2. Roman v. Roman, 193 S.W.3d 40 (Tex. App. 2006). 3. In re Marriage of Dahl and Angle, 222 Or. App. 572 (2008). 4. Terrell v. Torres, 248 Ariz. 47 (2020). 5. Bilbao v. Goodwin, 333 Conn. 599 (2019). 6. A.Z. v. B.Z., 431 Mass. 150, 725 N.E.2d 1051 (2000). 7. J.B. v. M.B., 170 N.J. 9, 783 A.2d 707 (2001). 8. Litowitz v. Litowitz, 146 Wash. 2d 514, 48 P.3d 261 (2002). 9. Reber v. Reiss, 42 A.3d 1131 (Pa. Super. Ct. 2012). 10. Szafranski v. Dunston, 2013 IL App (1st) 122975; 2015 IL App (1st) 122975-B. 11. In re Marriage of Rooks, 2018 CO 85. 12. In re Marriage of Witten, 672 N.W.2d 768 (Iowa 2003). 13. Arizona Revised Statutes § 25-318.03. 14. Evans v. United Kingdom, App. No. 6339/05, Grand Chamber, European Court of Human Rights (2007). Chapter 8 1. Surrogacy (Regulation) Act, 2021 (India). 1. Mennesson v. France, App. No. 65192/11, European Court of Human Rights (2014). 2. European Court of Human Rights, Advisory Opinion concerning the recognition in domestic law of a legal parent-child relationship between a child born through a gestational surrogacy arrangement abroad and the intended mother, Request No. P16-2018-001 (Grand Chamber, 2019). 3. Paradiso and Campanelli v. Italy, App. No. 25358/12, Grand Chamber, European Court of Human Rights (2017). 4. Case C-490/20, V.M.A. v. Stolichna obshtina, rayon "Pancharevo", Court of Justice of the European Union (2021). 5. Surrogacy Arrangements Act 1985 (UK); Human Fertilisation and Embryology Act 2008, s. 54 (UK). 6. Law Commission of England and Wales and Scottish Law Commission, Building Families Through Surrogacy: A New Law (2023). 7. Assisted Human Reproduction Act, S.C. 2004, c. 2 (Canada). 8. Executive Order 14160, "Protecting the Meaning and Value of American Citizenship" (Jan. 20, 2025). 9. Hague Conference on Private International Law, Parentage / Surrogacy Project, reports of the Experts' Group. Glossary Assisted reproductive technology (ART). Fertility treatments in which eggs or embryos are handled outside the body, including in vitro fertilization; state parentage statutes often use the broader term "assisted reproduction," which also covers insemination. Confirmatory adoption. An adoption by a person who is already a legal parent, obtained to secure a court judgment of parentage that must be recognized in every state and is more readily recognized abroad. Disposition. What happens to stored embryos: continued storage, transfer, donation to another patient, donation to research, or thawing without transfer. Gestational carrier. A woman who carries a pregnancy that began with an embryo created from someone else's egg, and who therefore has no genetic connection to the child. Intended parent. A person who initiates assisted reproduction or a surrogacy arrangement with the intention of being the legal parent of the resulting child. Judgment of parentage. A court order declaring who a child's legal parents are; in surrogacy it may be entered before birth (a pre-birth order) or after it (a post-birth order). Marital presumption. The rule that a child born to a married woman is presumed to be the child of her spouse; after Pavan v. Smith it must be applied equally to same-sex spouses. Reciprocal IVF. An arrangement in which one woman provides the egg and her female partner carries the pregnancy, so that each has a biological connection to the child. Second-parent adoption. An adoption by the partner of a legal parent that does not terminate the existing parent's rights. Traditional surrogate. A woman who conceives with her own egg, usually by insemination, and carries the pregnancy for intended parents; she is the child's genetic mother. Voluntary acknowledgment of parentage. A signed form, usually completed at the hospital, that establishes parentage without a court proceeding; originally limited to fathers, it has been extended in some states to intended parents in assisted reproduction. Further Reading Naomi R. Cahn, Test Tube Families: Why the Fertility Market Needs Legal Regulation (New York University Press, 2009).** A clear argument, by a leading family law scholar, that the American fertility industry's reliance on private ordering leaves children and parents exposed, with proposals for reform. Debora L. Spar, The Baby Business: How Money, Science, and Politics Drive the Commerce of Conception (Harvard Business School Press, 2006).** An account of assisted reproduction as a market, useful for understanding the economic forces behind surrogacy and gamete donation. John A. Robertson, Children of Choice: Freedom and the New Reproductive Technologies (Princeton University Press, 1994).** The classic statement of procreative liberty as the organizing principle for the law of assisted reproduction; much of the later case law, including the embryo disposition cases, engages with its arguments. Judith Daar, The New Eugenics: Selective Breeding in an Era of Reproductive Technologies (Yale University Press, 2017).** A critical examination of who has access to assisted reproduction and on what terms, by one of the field's principal legal scholars. I. Glenn Cohen, Patients with Passports: Medical Tourism, Law, and Ethics (Oxford University Press, 2015).** Includes a detailed treatment of cross-border reproductive care and international surrogacy. Douglas NeJaime, "Marriage Equality and the New Parenthood," Harvard Law Review 129 (2016): 1185, and "The Nature of Parenthood," Yale Law Journal 126 (2017): 2260.** Two influential articles tracing how parentage law has moved from biology toward intention and conduct, and arguing for parity for same-sex and non-biological parents. Marsha Garrison, "Law Making for Baby Making: An Interpretive Approach to the Determination of Legal Parentage," Harvard Law Review 113 (2000): 835.** A careful counterpoint to intent-based approaches, arguing that parentage rules for assisted reproduction should track those for natural conception. Uniform Law Commission, Uniform Parentage Act (2017), with official comments. The model statute behind many current state reforms; its comments explain the reasoning for its surrogacy and assisted reproduction provisions and are the best single guide to the modern statutory approach. Law Commission of England and Wales and Scottish Law Commission, Building Families Through Surrogacy: A New Law (2023).** An exhaustive comparative study and reform proposal; valuable to American readers as a detailed account of an alternative model. American Society for Reproductive Medicine, Practice Committee and Ethics Committee opinions. Published in Fertility and Sterility and available on the society's website, these opinions on gestational carriers, embryo disposition and related subjects set the professional standards that many statutes incorporate. Hashtags: #ReproductiveTechnologyLaw #AssistedReproductiveTechnology #ARTLaw #ReproductiveLaw #ReproductiveRights #ReproductiveJustice #SurrogacyLaw #GestationalSurrogacy #TraditionalSurrogacy #SurrogacyAgreements #SurrogacyContracts #SurrogacyRegulation #CommercialSurrogacy #SurrogatesRights #IntendedParents #LegalParentage #ParentageLaw #ParentageDetermination #PreBirthOrders #PostBirthOrders #ParentageJudgments #BirthCertificates #ConfirmatoryAdoption #FamilyFormationLaw #FamilyLaw #FertilityLaw #IVFLaw #InVitroFertilization #IVF #FertilityTreatment #AssistedReproduction #EmbryoLaw #EmbryoDisputes #FrozenEmbryoDisputes #EmbryoDisposition #EmbryoCryopreservation #EmbryoCustody #EmbryoOwnership #EmbryoPersonhood #EmbryoStorage #EmbryoDonation #GameteDonation #EggDonation #SpermDonation #DonorConception #ReproductiveConsent #InformedConsent #ClinicConsentForms #FertilityClinicRegulation #ReproductiveAutonomy #BodilyAutonomy #MedicalLaw #HealthcareLaw #Bioethics #ReproductiveBioethics #LegalEthics #ContractEnforceability #UniformParentageAct #SameSexParentage #LGBTQFamilyLaw #ReciprocalIVF #PosthumousReproduction #InheritanceLaw #CrossBorderSurrogacy #InternationalSurrogacy #InternationalFamilyLaw #CitizenshipAndParentage #ChildrensRights #BestInterestsOfTheChild #LegalRecognitionOfParenthood #ReproductiveHealthcarePolicy #StateSurrogacyLaws #BabyMCase #JohnsonVCalvert #DobbsVJackson #ObergefellVHodges #PavanVSmith #AssistedReproductionRegulation #ReproductiveTechnologyEthics

Download the Book (PDF): Introduction In 2016 Airbus showed a piece of aircraft cabin that looked as if it had been grown rather than built. It was a partition, the wall that separates the passenger cabin from the galley on an A320, and it had to hold a fold-down seat for cabin crew, survive the loads of a crash landing, and fit through the aircraft door. The conventional version is a honeycomb sandwich panel, flat and rectilinear. The new one was a lattice of thin, branching struts that resembled the cell walls of a slime mould or the inside of a bone. Airbus reported that it weighed 45 per cent less than the existing design, about 30 kilograms lighter, and estimated that applying the approach across the cabin and the A320 backlog could save up to 465,000 tonnes of carbon dioxide a year. The part was printed in a scandium-bearing aluminium alloy by APWorks, an Airbus subsidiary, and its geometry had been generated by software from Autodesk working with a design studio called The Living. Photographs of that partition, and of a hundred similar objects since, have become the visual signature of something called generative design. The strange organic forms are seductive. They suggest a machine with its own imagination, conjuring shapes no human would have drawn. It is easy to come away from the photographs believing that artificial intelligence now designs aircraft parts, buildings and car bodies, and that engineers are on the way to becoming supervisors of a creative process they no longer perform. This booklet argues that the photographs mislead in an important way. The shape is the least interesting thing about the partition. What made it possible was a precise statement of a problem: where the part attaches, which loads it must carry in which directions, how much it may deflect, what material it is made of, how it will be manufactured, and what is to be minimised. Given that statement and a reliable way to compute how any candidate shape behaves, a search procedure can find a remarkably good answer. Without that statement it can find nothing at all. The algorithm does not know what a crash load is, or that a partition must be installable, or that a strut thinner than the printer can resolve will not exist. Everything the algorithm "knows" about the world arrives through the problem definition and through the simulation that scores each candidate. That is the controlling idea of what follows. Generative design does not remove engineering judgement from the design process; it moves it. The judgement that once went into drawing a shape now goes into specifying the problem and into trusting, or distrusting, the evaluator that scores the answers. A search procedure will optimise exactly what it is told to optimise, as far as its model of physics allows, and it will exploit every gap between what was asked for and what was meant. The quality of a generated design is therefore bounded on one side by the honesty and completeness of the problem statement, and on the other by the fidelity of the simulation. The engineer who understands this gets extraordinary results. The engineer who does not gets beautiful, confident, wrong answers. What the term covers "Generative design" is used loosely, and some precision helps. In this booklet it means a design process in which the designer specifies goals and constraints rather than a geometry, and a computational procedure produces candidate geometries that are evaluated against those goals, usually many of them, usually iteratively. The procedure might be an evolutionary algorithm that breeds and mutates candidate designs, a gradient-based topology optimiser that sculpts material out of a block, a Bayesian optimiser steering an expensive simulation, or, increasingly, a neural network trained on previous designs and simulations. What these share is the inversion of the usual relationship between designer and form. In conventional computer-aided design the human proposes a shape and the software analyses it. In generative design the human proposes the criteria and the software proposes the shapes. The description of this booklet emphasises evolutionary algorithms, and they deserve the emphasis. They are the oldest and most general of the generative methods, the ones that need least from the problem and therefore apply most widely, and they introduced the vocabulary of populations, fitness and trade-off fronts that the whole field still uses. But an honest account must also say where they are the wrong tool. For the classic lightweighting problem, carving the stiffest possible bracket out of a given volume, gradient-based topology optimisation is faster by orders of magnitude and is what commercial software overwhelmingly uses. Evolutionary methods shine elsewhere: where the objective is noisy or discontinuous, where the design variables are a mix of numbers and choices, where several goals pull against each other, and where no gradient is available because the evaluator is a black box. Knowing which tool belongs to which problem is itself part of the judgement this booklet is about. Three domains, one logic The chapters move through three domains that look different on the surface and turn out to share a structure. The first is structural lightweighting, especially in aerospace, where a kilogram removed from an aircraft saves fuel on every flight for decades, and where the economics of removing mass are therefore more forgiving of exotic geometry and expensive manufacturing than almost anywhere else. Here generative methods have their clearest commercial successes, and here the partnership with additive manufacturing, which can build the forms the algorithms propose, is most developed. The second is aerodynamic shape, the design of wings, nozzles, train noses and turbine blades, where the evaluator is computational fluid dynamics and the cost of a single evaluation can run to hours on a cluster. Here the central problem is economy: how to search a shape space intelligently when you can afford only a few hundred looks at it. Evolutionary methods, adjoint gradients and surrogate models have each found their place, and the field offers the clearest lessons about how the representation of a shape determines what can be found. The third is the thermal and environmental behaviour of buildings, where the evaluator is building performance simulation and the objectives are energy use, daylight, comfort and cost. Buildings are responsible for roughly a third of global energy-related carbon emissions, according to the United Nations Environment Programme's annual status reports on the sector, and most of a building's lifetime energy performance is fixed by decisions taken in the first weeks of design, when the massing, orientation and window ratios are chosen. Generative methods promise to bring performance into those early decisions. They also run into the largest gap between simulated and real behaviour of any domain in the booklet, which makes buildings the sharpest test of the controlling idea. Across all three, the same pattern repeats. A good result requires a representation that can express good designs, an evaluator that can tell good from bad for the right reasons, a search procedure matched to the problem, and a problem statement that captures what actually matters. When any of the four is weak, the results disappoint, and the failure is almost never in the search procedure itself. How the book proceeds Chapter 1 sets out what generative design is by tracing the shift from drawing to specifying, and the long lineage behind it, from structural theory at the start of the twentieth century to the visual programming tools that brought optimisation into architecture. Chapter 2 explains how evolutionary search actually works: representation, variation, selection, and the trade-off front that multi-objective methods produce. Chapter 3 turns to topology optimisation, the technique behind most lightweight parts, and explains why gradient methods dominate it and what evolutionary methods still contribute. Chapter 4 follows these methods into aerospace hardware, where the obstacles turn out to be certification, fatigue and qualification rather than geometry. Chapter 5 takes up aerodynamic shape optimisation and the economics of expensive evaluation. Chapter 6 applies the same logic to building thermodynamics. Chapter 7 examines what machine learning adds, from surrogate models that replace slow simulations to generative networks that propose geometry directly and the newest systems that generate editable CAD. Chapter 8 asks where, in the end, the engineer's judgement goes, and what an organisation must do to keep it there. The book assumes an interested reader rather than a specialist: an engineer from another discipline, an architect, a manager deciding whether to invest in these tools, a student. It contains no equations, because the ideas can be stated without them. It does contain occasional technical terms, defined where they first appear, because pretending the field has no vocabulary would leave the reader unable to follow anything written about it elsewhere. One caution before beginning. Much of what is written about generative design comes from software vendors and from the press offices of companies that have used it, and the figures they report, a percentage saved here, a number of parts consolidated there, are real claims about real projects but rarely come with the baseline, the full set of constraints, or the cost of qualification. Where this booklet cites such figures it attributes them, and the reader should read them as what the organisation reported, not as independently audited results. That caution is not cynicism. It is the same discipline the field itself demands: an optimised number is only as meaningful as the problem it was optimised against. Chapter 1: From Drawing to Specifying For most of the history of engineering, design meant proposing a form and then checking it. An engineer sketched a bracket, a beam, a hull, estimated the loads, calculated the stresses, and adjusted the dimensions until the numbers came out right. The form came first, from experience, convention and intuition; analysis came second, as a test the form had to pass. Computers, when they arrived in design offices, slotted neatly into this sequence. They made drawing faster and analysis more powerful, but they did not change who proposed the shape. Generative design changes that. It asks the designer to state what the object must do, under what conditions, within what limits, and then lets a computational procedure propose forms that satisfy the statement. The human moves from author of the shape to author of the question. That sounds like a small reordering. In practice it changes what an engineer needs to know, where errors enter, and what it means to be good at the job. The long road to the question The idea that form should follow from a precise statement of function, rather than from convention, is much older than computers. In 1904 the Australian engineer Anthony Michell published a short paper in the Philosophical Magazine on "the limits of economy of material in frame-structures". Michell asked what layout of bars would carry a given load to given supports using the least possible material, and he proved that the optimal frames have a characteristic geometry: members that meet at right angles and follow curving families of lines, like the patterns of iron filings around a magnet. Michell's structures were almost impossible to build with the materials and methods of his day. But his paper established that, for a properly stated problem, there is an ideal form, that it can be derived rather than guessed, and that it often looks nothing like what a designer would sketch. More than a century later, the output of topology optimisation software still echoes Michell's curving, orthogonal webs. Architects arrived at a similar idea by physical rather than mathematical means. Antoni Gaudí, designing the crypt of the Church of Colònia Güell near Barcelona in the 1890s and 1900s, built hanging models from strings weighted with small bags of shot. A hanging chain takes up a shape in pure tension; flip it upside down and it gives the shape of an arch in pure compression. By loading the strings in proportion to the weight of the masonry they represented, Gaudí let gravity compute the forms of his vaults. Half a century later Frei Otto did something comparable with soap films and wire frames to find the minimal surfaces that became the tensile roofs of the 1972 Munich Olympic stadium. These are form-finding methods: the designer sets the boundary conditions and the loads, and a physical process finds the shape. The designer's skill lies in choosing which boundary conditions and which loads to impose, and in recognising when the result is good. The computational lineage began in the 1960s. Lucien Schmit, working on aircraft structures, argued in 1960 for what he called structural synthesis: coupling finite element analysis to numerical optimisation so that the computer could adjust member sizes automatically to minimise weight while keeping stresses and displacements within limits. Through the 1970s and 1980s, sizing optimisation (adjusting thicknesses and cross-sections) and shape optimisation (moving boundaries) became established tools in aerospace and automotive engineering. The decisive step came in 1988, when Martin Bendsøe and Noboru Kikuchi published a method for generating optimal topologies, that is, deciding not merely how thick each member should be or where each boundary should lie, but where material should exist at all and how many holes the part should have. Topology optimisation, which Chapter 3 examines in detail, is the direct ancestor of most of the lightweight parts that now illustrate articles about generative design. In parallel, a different tradition was growing in computer science. John Holland's work on genetic algorithms, published in book form in 1975, and the evolution strategies developed in Berlin from the 1960s by Ingo Rechenberg and Hans-Paul Schwefel, showed that a population of candidate solutions, varied at random and filtered by selection, could find good answers to problems that defeated classical mathematics. Rechenberg's early experiments were physical: plates hinged together and set in a wind tunnel, their angles adjusted by dice throws, the configuration with lower drag kept for the next round. Chapter 2 explains how these methods work. Their relevance here is that they made it possible to optimise designs where the relationship between the variables and the outcome was too complicated to write down, so long as the outcome could be measured or simulated. The final ingredient was a way for designers, rather than specialist programmers, to state problems. In architecture this arrived with visual programming environments, above all Grasshopper, a plug-in for the Rhinoceros modelling software released in the late 2000s, in which designers build parametric models by wiring together boxes that each perform an operation. A Grasshopper model is a recipe: change the number feeding into one box and the whole geometry regenerates. In 2010 David Rutten, Grasshopper's author, added Galapagos, an evolutionary solver that could be wired to any numeric output of the model and told to minimise or maximise it by adjusting any set of sliders. Suddenly an architect who could build a parametric model could also run an optimisation on it, coupling geometry to daylight analysis, solar exposure or structural deflection. Multi-objective solvers such as Octopus and Wallacei followed. In mechanical engineering, commercial generative design tools reached mainstream CAD packages in the second half of the 2010s, packaging topology optimisation and related methods behind interfaces that asked engineers for loads and constraints rather than for geometry. The anatomy of a generative problem Whatever the domain and whatever the algorithm, a generative design problem has the same parts, and naming them clearly is the first step to using these methods well. The design space is the set of all designs the procedure can produce. In a structural problem it is often a physical volume, the region of space the part may occupy, together with regions it must occupy (keep-in regions around bolt holes and mounting faces) and regions it must avoid (keep-out regions for cables, adjacent parts or the path of a moving mechanism). In an architectural problem it might be the range of possible building footprints, heights, orientations and window-to-wall ratios. The design space is defined by its representation, the scheme that turns a handful of numbers or symbols into a geometry. This matters more than it appears. A representation that describes a wing by eight control points can produce only the wings that eight control points can describe. A representation that allows any distribution of material in a block can produce shapes nobody anticipated, but also shapes nobody can make. The objectives are what the procedure tries to improve: minimise mass, maximise stiffness, minimise drag, minimise annual heating and cooling energy, maximise useful daylight. A problem with one objective has, in principle, one best answer. A problem with several objectives that conflict, as they almost always do, has instead a set of answers representing different trade-offs, and choosing among them is a human decision. The constraints are conditions every acceptable design must satisfy: stress below the allowable for the material, deflection below a limit, natural frequency above a threshold, a minimum wall thickness the manufacturing process can achieve, a maximum budget, a building code requirement. Constraints and objectives are often interchangeable in formulation. One can minimise mass subject to a stiffness requirement, or maximise stiffness subject to a mass budget, and the choice changes the answer. The evaluator is whatever computes how a candidate design performs: a finite element model, a fluid dynamics simulation, an energy simulation, a cost model, or a trained neural network standing in for one of these. Every number the search procedure sees comes from the evaluator. If the evaluator is wrong about some class of designs, the search will happily converge on that class. The search procedure is the algorithm that proposes candidates and uses their evaluations to propose better ones. This is the part that attracts most attention and, in practice, the part least often responsible for disappointing results. Laid out like this, the shift in the designer's role becomes concrete. In conventional design, the engineer's judgement went into the shape, and the analysis checked it. In generative design, the engineer's judgement goes into the design space, the representation, the objectives, the constraints and the choice and calibration of the evaluator. The shape is the output of that judgement rather than its direct expression. A bracket, stated properly Consider a modest example: a bracket that holds a piece of equipment to an aircraft frame. A conventional design process might begin with a sketch based on a similar bracket from a previous programme, a machined aluminium part with two flanges and a web. A generative process begins elsewhere. The engineer must state where the bracket bolts to the frame and where the equipment bolts to the bracket, which fixes the keep-in regions. They must state the envelope available, which means knowing about the cable bundle that runs alongside and the inspection access a maintenance technician will need, which fixes the keep-out regions. They must state the load cases: not merely the static weight of the equipment, but the inertial loads in a hard landing, the loads in an emergency landing as set out in the certification requirements, the vibration environment of the frame, perhaps the thermal expansion mismatch between the bracket and what it attaches to. Each load case is a direction, a magnitude and a point of application. Missing one is the classic error: an optimiser given only the vertical landing load will produce a bracket superbly efficient in that direction and dangerously weak sideways, because it was never told that sideways mattered. They must state the material and its allowable stresses, which depends on the manufacturing process, since a printed titanium alloy, a cast aluminium and a forged aluminium have different properties and different scatter. They must state the manufacturing constraints: a minimum feature size, a maximum overhang angle for additive manufacturing, a draw direction for casting, tool access for machining. They must state the objective, perhaps minimum mass, and the constraints, perhaps a maximum deflection at the equipment mounting point and a minimum first natural frequency so that the bracket does not resonate with the engine. Only then can the software run. And when it returns a shape, the engineer must judge whether that shape is good for reasons the software could not see. Are there thin members that would be vulnerable to damage during maintenance? Are there stress concentrations at the junctions that a coarse mesh smoothed over? Will the surface finish of a printed part reduce its fatigue life below what the static analysis assumed? Can it be inspected? Has the shape exploited some quirk of the boundary conditions, such as a bolt hole modelled as perfectly rigid when the real joint will slip a little? Most of this list is not new. A good engineer designing the bracket by hand would have considered every item. What is new is where the consideration happens and how visible its absence is. In a hand design, a missing lateral load case might be partly covered by the designer's instinct for robust proportions; a human sketching a bracket draws something that looks sturdy in every direction because that is what brackets look like. An optimiser has no such instinct. It strips away every gram that the stated problem does not require, which means the stated problem has to contain everything that matters. Generative design converts tacit engineering knowledge into explicit problem statements, and wherever the knowledge stays tacit, the design is exposed. Optimisation, exploration and the meaning of "generative" There is a debate, more than terminological, about whether generative design is simply optimisation under a new name. Some researchers distinguish the two sharply. Optimisation, on this view, finds the best point in a well-defined space against a well-defined objective. Generative design, by contrast, is about exploration: producing a wide variety of distinct, plausible options that help the designer understand the problem and discover what they want. Sivam Krish, in a 2011 paper in Computer-Aided Design, argued for generative design as a way to explore a design space broadly in the early, ill-defined stages of a project, with the designer steering by preference rather than by a formal objective. Both modes are real, and good practice uses both. Early in a project, when the objectives themselves are uncertain, running many variations with different constraints and different weightings of goals reveals the shape of the trade-offs: how much mass a stiffer design costs, how quickly the energy penalty rises as window area grows, which constraint is really binding. This exploratory use treats the algorithm as a way of asking the problem questions. Later, when the problem is fixed, the same machinery converges on a refined solution. The distinction matters because the two modes demand different things. Exploration needs speed and diversity, so cheap approximate evaluators are fine. Final optimisation needs accuracy, so the evaluator must be trusted in precisely the regions of the design space where the optimum lies. The exploratory mode also clarifies something about the "creativity" often attributed to these systems. When a generative process returns a form that surprises its designers, the surprise usually means the problem statement allowed something the designers had not imagined. Sometimes that is a genuine discovery, a load path more efficient than convention suggested. Sometimes it is a sign that the problem statement is missing a constraint. The algorithm cannot tell these apart. The designer must. Why now If the ideas are decades old, why has generative design moved from research papers to mainstream engineering software only in the last ten to fifteen years? Three developments converged. The first is cheap computation. A topology optimisation of a realistic three-dimensional part requires solving a large finite element problem dozens or hundreds of times. An evolutionary search may need thousands of evaluations. Cloud computing made it practical to run many such problems in parallel, which is why commercial generative design tools often present several dozen outcomes at once, each from a different combination of material, manufacturing method and constraint. The second is additive manufacturing. The forms that unconstrained topology optimisation produces, with their organic branches and internal voids, are difficult or impossible to machine or cast. Metal powder-bed fusion and related processes can build many of them. This removed a long-standing objection to structural optimisation, that its outputs had to be heavily simplified before they could be made, and created an industry with a strong economic interest in geometry that exploits the freedom of printing. The relationship runs both ways: generative design gives additive manufacturing parts that justify its cost, and additive manufacturing gives generative design parts that can actually be built. The third is the integration of simulation into design tools. Two decades ago, finite element analysis was typically performed by specialists in separate software, on geometry handed over from the design department. Today, simulation is embedded in the CAD tools designers use daily, and in architecture, environmental analysis runs inside the same parametric environment as the geometry. A generative loop needs the evaluator and the geometry to talk to each other thousands of times without a human in between. That integration is what made the loop practical. A fourth development, still unfolding as of 2026, is machine learning. Neural networks trained on simulation results can predict performance in milliseconds rather than hours, and generative models can propose geometry directly. Chapter 7 examines what these add and what they do not. They change the economics of the evaluator dramatically, but they do not change the basic structure of the problem. A neural network that predicts drag is still an evaluator, and it can still be wrong in exactly the places an optimiser most wants to go. The shift in responsibility The practical consequence of all this is that responsibility in a generative design process concentrates at the front, in problem definition, and at the back, in verification, while the middle, where the form is actually produced, becomes automated. This is the reverse of the traditional distribution of effort, in which the middle consumed most of a designer's time. Organisations that adopt generative design without recognising this shift tend to repeat a familiar story. Enthusiastic early users produce striking parts. Some of them fail testing, or cannot be manufactured, or turn out to be optimised for the wrong thing, and confidence drops. The tool is blamed. In almost every such story, the tool did exactly what it was asked. What failed was the asking. The chapters that follow examine each element of the generative problem in turn, beginning with the search procedure that gave the field much of its vocabulary: evolution. Chapter 2: How Evolution Searches In March 2006 NASA launched three small satellites, the Space Technology 5 mission, to test technologies for constellations of tiny spacecraft studying Earth's magnetosphere. Each carried an X-band antenna that looked like a paperclip someone had bent absent-mindedly: a short stem with a few wire arms twisting off at irregular angles. No antenna engineer had drawn it. A team at NASA Ames Research Center, led by Jason Lohn, Derek Linden and Gregory Hornby, had specified what the antenna must do (its frequency band, its gain pattern, its impedance match, the volume it had to fit into) and let an evolutionary algorithm search for wire shapes that met the specification, evaluating each candidate with electromagnetic simulation. The evolved antenna met the mission requirements, and the team reported in a 2011 paper in Evolutionary Computation that it was the first computer-evolved hardware to fly in space. When the mission's orbit changed during the programme, they were able to evolve a new design for the revised requirements in weeks. The antenna is the canonical example of evolutionary design, and it illustrates almost everything worth understanding about how these methods work. The search did not need to know anything about antenna theory. It needed only a way to describe a candidate (a sequence of wire segments with lengths and angles), a way to score it (simulation against the requirement), and a procedure for using scores to propose better candidates. The resulting shape was strange because the problem statement did not ask for it to be familiar. And the method was valuable less because it found a shape no human could have found than because, once the specification was encoded, it could find a new compliant shape quickly whenever the specification changed. The basic loop An evolutionary algorithm maintains a population of candidate designs. In each generation, it evaluates every candidate, selects some of the better ones to be parents, creates new candidates from the parents by recombination and mutation, and forms the next generation from the offspring, often together with the best of the parents. The loop repeats for dozens or hundreds of generations, until the improvement stalls or the computing budget runs out. Each element of this loop has design choices that matter. Representation. The algorithm manipulates an encoding of the design, sometimes called its genotype, and the evaluator scores the design that the encoding produces, sometimes called its phenotype. The simplest encoding is a list of numbers: the angles and lengths of antenna segments, the thicknesses of a set of panels, the control points of a curve. Holland's original genetic algorithms used strings of binary digits, and much early theory was built around them, but practical engineering applications now mostly use real numbers directly. Other encodings are richer. A tree of operations can describe a structure built by successive branching. A set of grammar rules can generate building layouts or truss topologies. A graph can describe which components connect to which. The Space Technology 5 team experimented with encodings that described the antenna as a set of construction instructions, like a small program, rather than as a fixed list of coordinates, because this let the search reuse useful sub-structures. The choice of representation decides what the search can find and how easily. If the representation can only describe smooth curves, no amount of evolution will produce a sharp corner. If it describes a structure as a long string where neighbouring numbers are unrelated in the physical design, recombination will mostly destroy good arrangements rather than combine them. Engineers who work with these methods often say the representation is more important than the algorithm, and the evidence supports them. Fitness. The fitness of a candidate is the number, or set of numbers, the algorithm uses to compare it with others. In the simplest case it is the objective itself, such as mass or drag. Constraints complicate matters. One common approach adds a penalty to the fitness of any candidate that violates a constraint, scaled by how badly it violates it, so that infeasible designs are discouraged but not forbidden outright, which lets the search pass through infeasible regions on the way to good feasible ones. Choosing the penalty weights is fiddly: too small and the search converges on infeasible designs that happen to score well, too large and it gets trapped. Kalyanmoy Deb proposed a cleaner alternative in 2000: when comparing two candidates, a feasible one always beats an infeasible one, two feasible ones are compared on the objective, and two infeasible ones are compared on how badly they violate the constraints. This requires no weights and has become a standard technique. Selection. Selection decides which candidates become parents. Tournament selection, in which a few candidates are drawn at random and the best of them is chosen, is popular because it is simple and its pressure is easy to tune by changing the tournament size. Elitism, carrying the best few candidates into the next generation unchanged, ensures that the best design found so far is never lost. The balance of selection pressure is a balance between exploitation, concentrating on the best region found, and exploration, keeping enough diversity to find better regions elsewhere. Too much pressure and the population collapses onto a single mediocre design; too little and the search wanders. Variation. Recombination, or crossover, creates a child by mixing the encodings of two parents. Mutation perturbs a child's encoding at random. For real-valued encodings, mutation typically adds a small random number to each variable, and the size of these perturbations matters a great deal: large steps explore widely but rarely improve a good design, small steps refine but cannot escape a local basin. Evolution strategies and learning the landscape The Berlin school took a different emphasis from Holland's. Rechenberg and Schwefel's evolution strategies, developed for engineering optimisation from the 1960s, worked with real numbers from the start and put mutation, rather than crossover, at the centre. Their key insight was that the step size of mutation should adapt as the search proceeds. Rechenberg proposed a simple heuristic, often called the one-fifth success rule: if more than about a fifth of mutations improve on their parent, the steps are too timid and should grow; if fewer, the steps are too bold and should shrink. Later evolution strategies made the step sizes part of the encoding itself, so that they evolved along with the design. The most important descendant of this line is the covariance matrix adaptation evolution strategy, CMA-ES, developed by Nikolaus Hansen and Andreas Ostermeier and published in its established form in 2001. CMA-ES samples new candidates from a multivariate normal distribution and, generation by generation, adjusts not only the centre and overall spread of that distribution but its shape and orientation, learning which combinations of variables tend to produce improvement. If the good designs lie along a narrow diagonal valley in the design space, where increasing one variable is beneficial only when another decreases, CMA-ES learns to stretch its sampling distribution along that valley. In effect it builds up a picture of the local curvature of the landscape without ever computing a gradient. For continuous problems with up to perhaps a hundred variables and no gradient information, CMA-ES is among the most reliable general-purpose methods available, and it is widely used in aerodynamic and structural shape optimisation. Many objectives, one front Real engineering problems rarely have a single objective. A wing should have low drag and low weight. A building should use little energy and admit plenty of daylight and cost little to build. These goals conflict: the lightest wing is not the one with the least drag, and the building with the most glass gets the most daylight and the worst heat loss. One way to handle conflicting objectives is to combine them into one number with weights, for example by converting everything into money. This is sometimes appropriate, but it forces the designer to commit to the weights before seeing what the trade-offs look like, and a weighted sum cannot find certain kinds of compromise at all when the trade-off curve bends the wrong way. The alternative is to search for the whole set of best compromises. A design is said to dominate another if it is at least as good on every objective and strictly better on at least one. A design that no other design dominates is called Pareto-optimal, after the economist Vilfredo Pareto, and the set of all such designs forms the Pareto front: the frontier along which improving one objective necessarily worsens another. Everything behind the front is simply inferior; everything on it is a legitimate choice, and choosing among them requires values the algorithm does not have. Evolutionary algorithms are naturally suited to finding Pareto fronts because they work with populations. A single run can maintain many candidates spread along the front. The most widely used method, NSGA-II, published by Deb and colleagues in 2002, ranks the population into layers: first the non-dominated designs, then those dominated only by the first layer, and so on. Within a layer, it prefers designs in sparsely populated regions of the front, measured by a quantity called crowding distance, so that the population spreads out along the whole trade-off curve rather than clustering at one end. NSGA-II and its successors, including NSGA-III for problems with many objectives, are built into most multi-objective tools used in engineering and architecture. The Pareto front is one of the most useful things a generative process can show a designer, because it turns an argument about preferences into a picture of possibilities. A team debating whether to accept a heavier part for a stiffer one can see exactly how much stiffness each extra gram buys, and where the curve flattens so that further mass gains almost nothing. Shigeru Obayashi and colleagues in Japan, who applied multi-objective evolutionary algorithms to aircraft wing design from the late 1990s, went further and used data-mining techniques such as self-organising maps to analyse the designs on the front, extracting which design variables drove which trade-offs. This turned optimisation into a way of learning about the design problem, which is often more valuable than any single optimal design. What evolution is good at, and what it is not The great strength of evolutionary methods is how little they require. They need no gradient, no smoothness, no continuity. They can handle design variables that are integers or categorical choices (number of ribs, choice of material, which of several components to use) alongside continuous ones. They tolerate noisy evaluations, such as simulations that converge slightly differently each time. They can wrap around any evaluator that returns a number, including commercial simulation software whose internals are inaccessible. And because each candidate in a generation can be evaluated independently, they parallelise trivially across as many computers as are available. Their great weakness is appetite. An evolutionary algorithm typically needs thousands or tens of thousands of evaluations to converge on a problem with tens of variables, and the number grows with the number of variables. When each evaluation is a fluid dynamics simulation taking hours, that is prohibitive. And as the number of variables reaches into the thousands or millions, as it does in topology optimisation where every element of a finite element mesh is a variable, evolutionary methods become hopeless compared with methods that use gradients. Chapter 3 returns to this point because it is widely misunderstood. There is also a theoretical limit worth knowing. In 1997 David Wolpert and William Macready proved what are called the no free lunch theorems for optimisation: averaged over all possible problems, every search algorithm performs equally well. An algorithm that does better on some class of problems must do worse on others. This does not mean algorithm choice is irrelevant; real engineering problems are not drawn uniformly from all possible problems, and they have structure, such as smoothness and correlation between nearby designs, that good algorithms exploit. But it does mean there is no universally best method, and that matching the algorithm to the structure of the problem is part of the engineer's job. The main families of search methods available to a generative designer differ along a few consistent dimensions, as Table 1 sets out: whether they need gradients, roughly how many evaluations they consume, whether they handle discrete choices, and the kind of problem they suit. Table 1. Main families of search methods used in generative design. Method Needs gradients Typical evaluation budget Discrete variables Best suited to Genetic algorithms, NSGA-II No Thousands to tens of thousands Yes Mixed variables, several objectives, cheap evaluators CMA-ES and evolution strategies No Hundreds to thousands Poorly Continuous shape variables, rugged landscapes Gradient-based (adjoint) Yes Tens to hundreds of iterations No Thousands to millions of variables, smooth physics Bayesian optimisation with surrogates No Tens to a few hundred With care Very expensive evaluators, few variables The table simplifies a great deal, and hybrids are common: an evolutionary algorithm exploring broadly with a surrogate model filtering its candidates, or a gradient method refining the best designs an evolutionary search found. But it captures the basic economics. The cheaper the evaluator and the stranger the landscape, the more attractive evolution becomes. The more variables and the smoother the physics, the more decisively gradients win. Exploiting the evaluator One phenomenon deserves special attention because it recurs in every domain this booklet covers, and because evolutionary methods, with their indifference to how the evaluator works, are especially prone to it. An optimiser will find and exploit any flaw in its evaluator that produces a good score. Researchers in evolutionary computation have collected many examples, some of them comic. Simulated creatures evolved to move quickly learned to exploit numerical errors in the physics engine, gaining energy from collisions that should have conserved it. Circuits evolved on reconfigurable chips used electromagnetic coupling between supposedly disconnected components, so that the design worked only on the particular chip on which it had evolved. In engineering design the same phenomenon appears more soberly: a structural optimiser finds that a coarse mesh underestimates stress in thin members and so makes members ever thinner; an aerodynamic optimiser finds a shape that exploits a weakness of the turbulence model, producing a predicted drag reduction that vanishes in the wind tunnel; a building optimiser finds that a simplified daylight calculation overrates a particular window arrangement. The general principle is that optimisation pushes designs toward the edges of the evaluator's validity, because that is where the evaluator's errors are largest and therefore where spuriously good scores are most likely to be found. A random design scored by a simulation with ten per cent error is scored with ten per cent error. An optimised design is selected precisely because it scored well, which means it is disproportionately likely to be one where the error happened to be in its favour. This is the engineering version of a familiar statistical trap, sometimes called the optimiser's curse, and it means the final designs of any generative process deserve more scrutiny, not less, than designs produced by hand. The remedies are not algorithmic. They involve validating the evaluator in the region where the optimum lies, refining the analysis of final candidates with higher-fidelity methods, adding constraints that keep designs within the evaluator's range of validity, and maintaining a healthy suspicion of any result that looks too good. Each of these is an act of engineering judgement, which is the recurring theme of this booklet. The algorithm searches; the engineer decides what its findings are worth. The antenna revisited Return briefly to the Space Technology 5 antenna, because it shows the method used well. The team chose a representation suited to the physics, wire segments whose geometry could be built. They used a well-established electromagnetic simulation code as their evaluator, in a domain where such codes are accurate for wire antennas of that kind. Their fitness function encoded the actual mission requirements, not a proxy. And they built and tested the evolved designs, measuring their performance in an anechoic chamber before the antenna flew. The strangeness of the shape was not a sign of machine creativity. It was a sign that the specification had been encoded honestly and that the evaluator could be trusted. Those two conditions, far more than the cleverness of the algorithm, are what generative design depends on. Chapter 3: Carving with Gradients: Topology Optimisation Most of the lightweight parts that illustrate articles about generative design, the brackets with their branching struts, the hinges that look like tendons, the partitions that look like bone, were produced by a family of methods called topology optimisation. Many popular accounts describe these parts as "evolved", and some commercial tools have used evolutionary vocabulary in their marketing. Almost none of them were evolved in the technical sense of Chapter 2. They were computed by gradient-based optimisation, a fundamentally different kind of search that exploits mathematical structure evolutionary methods ignore. Understanding why matters, both because it explains what the tools are actually doing and because it shows clearly how the right search method depends on the structure of the problem. Material as a field Topology describes the connectivity of a shape: how many separate pieces it has, how many holes pass through it. Sizing optimisation adjusts the thickness of members whose layout is fixed. Shape optimisation moves the boundaries of a part but keeps its holes. Topology optimisation goes further and decides where material should exist at all, so it can open new holes, merge members and invent load paths. The breakthrough that made this practical was to stop thinking about the part as a shape and start thinking about it as a field. Divide the design space into a fine mesh of small elements, the same mesh a finite element analysis would use, and assign each element a density between zero (empty) and one (solid). The design is no longer a geometry with a boundary; it is a list of numbers, one per element. A three-dimensional part meshed for realistic analysis might have hundreds of thousands or millions of elements, so the design has hundreds of thousands or millions of variables. The classic problem is to minimise compliance, which is the inverse of stiffness and is measured as the work done by the applied loads, subject to a limit on total volume. In words: given a fixed amount of material, put it where it makes the structure as stiff as possible under the stated loads. If densities could take any value between zero and one, the optimiser would happily fill the design space with grey, half-dense material, which is not something that can be manufactured. Bendsøe and Kikuchi's original 1988 method dealt with this by modelling each element as a tiny periodic microstructure with holes, so intermediate densities had a physical meaning. A simpler approach, proposed by Bendsøe in 1989 and developed by others, especially George Rozvany and Ming Zhou, became the industry standard. It is called SIMP, for solid isotropic material with penalisation. Each element's stiffness is taken to be its density raised to a power, typically three. An element at half density then has only an eighth of the stiffness of a solid element, while still costing half the volume. Intermediate densities are therefore uneconomic, and the optimiser is pushed, though not forced, towards designs that are mostly solid or empty. Why gradients win here To improve a design, an optimiser needs to know which way to change it. For a problem with a million variables, an evolutionary method would have to discover by trial and error which of those million numbers to increase and which to decrease, and how they interact. Even a very efficient evolutionary method needs a number of evaluations that grows with the number of variables. With each evaluation being a finite element analysis of a million-element mesh, the cost is far beyond any practical budget. Gradient-based methods know the answer directly. For the compliance problem, a mathematical technique called the adjoint method yields the sensitivity of the objective to every single element density from the results of one finite element analysis plus a small amount of extra arithmetic. For compliance the problem is self-adjoint, which means the sensitivity of each element can be read off from the strain energy stored in it: elements working hard deserve more material, idle ones less. One analysis gives a complete map of which way to move all million variables at once. An optimiser then takes a step, re-analyses, recomputes the sensitivities and steps again. Typical problems converge in a hundred or a few hundred iterations, each costing roughly one finite element solve, regardless of whether the mesh has a thousand elements or a million. The update rules used are either optimality criteria methods, simple heuristics derived from the conditions an optimal design must satisfy, or general-purpose gradient algorithms such as the method of moving asymptotes, introduced by Krister Svanberg in 1987 and still a workhorse of the field. These algorithms handle the volume constraint and other constraints efficiently and are robust enough to run unattended. Ole Sigmund, one of the field's leading figures, made the point about evolutionary approaches bluntly in a 2011 paper in Structural and Multidisciplinary Optimization titled "On the usefulness of non-gradient approaches in topology optimization". He compared the computational effort of gradient-based topology optimisation with genetic algorithms and similar methods on representative problems and concluded that, for the standard topology optimisation problems, non-gradient methods were orders of magnitude more expensive and produced worse designs, except on tiny problems with coarse meshes that were of little practical use. He argued that the reported successes of non-gradient topology optimisation in the literature mostly concerned problems so small that the comparison was meaningless. The paper was deliberately provocative, and it was largely correct. How capable the gradient approach has become was demonstrated in 2017, when Niels Aage, Erik Andreassen, Boyan Lazarov and Sigmund published in Nature a topology optimisation of the internal structure of a full-scale aircraft wing using more than a billion voxels, run on a supercomputer. The resulting internal architecture abandoned the conventional arrangement of straight spars and ribs for curved, branching members that the authors compared to the structure of bird bones, and they reported mass savings of a few per cent in the wing structure relative to a conventional layout, a meaningful figure for something as heavily optimised as a wing. No evolutionary method could approach a problem of that size. Making the result buildable Raw topology optimisation has well-known pathologies, and much of the practical skill of the field lies in taming them. The first is the checkerboard: regions where solid and empty elements alternate like squares on a board. With certain simple element types, a checkerboard pattern appears artificially stiff because of a quirk of the numerical approximation, so the optimiser favours it. This is the exploitation of evaluator error described in Chapter 2, appearing at the level of individual elements. The second pathology is mesh dependence: refine the mesh and the optimiser finds a different, finer design with more and thinner members, and in the limit the problem has no well-defined solution at all, because ever finer microstructures keep improving stiffness. Both are cured by filtering. A sensitivity or density filter smooths each element's value with those of its neighbours within a chosen radius, which forbids features smaller than that radius. The filter radius becomes a minimum length scale, which is useful because it corresponds directly to a manufacturing constraint: the smallest member the process can build. Later refinements, called projection methods, sharpen the smoothed field back toward pure solid and void so the result is crisp, and can impose separate minimum sizes on solid members and on holes. Sigmund's 2001 paper presenting a complete topology optimisation code in 99 lines of MATLAB, and its 2011 successor by Erik Andreassen and colleagues in 88 lines, did a great deal to spread these ideas. Anyone could read the whole method in an afternoon and run it, and thousands of students and engineers did. The brevity also made a point: the core of the method is simple. The difficulty lies in formulation and in turning results into real parts. Other approaches to topology optimisation describe the boundary of the part differently. Level-set methods, developed in the early 2000s by Michael Yu Wang and colleagues and by Grégoire Allaire and colleagues, represent the part's boundary as the zero contour of a smooth function, which produces crisp boundaries throughout the optimisation. Evolutionary structural optimisation, despite its name, is not an evolutionary algorithm in the sense of Chapter 2: proposed by Yi Min Xie and Grant Steven in 1993, it removes lightly stressed material iteratively, and its bidirectional version also adds material where needed. It is a heuristic driven by sensitivity information and closely related to gradient methods in practice. All of these approaches share the essential feature of using local information from a single analysis to update every part of the design at once. Stress, fatigue and the problem with compliance Minimising compliance is mathematically convenient, but it is not what engineers usually care about. Parts fail when stresses exceed what the material can bear, or when cyclic stresses grow cracks over millions of cycles. A design that is as stiff as possible is often reasonably good on stress, because stiff designs spread load efficiently, but not reliably so. Sharp re-entrant corners and thin members at junctions can concentrate stress without much affecting overall stiffness. Adding stress constraints directly is hard. Stress is a local quantity, so in principle there is a constraint for every element, millions of them. Stress in a nearly empty element is ill-defined and can be large in a way that blocks the optimiser from ever removing material, a difficulty known in the literature as the singularity problem. Researchers have developed workable techniques, such as aggregating many local stress constraints into a few smooth global measures and relaxing the stress definition in low-density elements, and commercial tools now offer stress-constrained optimisation. But it remains more delicate than compliance minimisation, and fatigue, which depends on surface finish, residual stresses and material defects as much as on nominal stress, is harder still. In practice, engineers typically optimise for stiffness with conservative constraints, then check stress and fatigue in detailed analysis of the interpreted design and iterate. This gap between what the optimiser can easily handle and what the engineer actually needs is a recurring pattern. The objective is often a proxy. The proxy is chosen because it is tractable, and it correlates with the real goal across ordinary designs. Optimisation, by pushing designs into unusual territory, can break that correlation. Manufacturing as a constraint Early topology optimisation produced designs that were striking and almost unmakeable: organic webs with internal cavities and members at every angle. For decades engineers took these results as inspiration, then redrew a simplified version that could be machined or cast, losing much of the benefit along the way. Two developments changed this. The first was additive manufacturing, which can build many of the raw forms. The second was the incorporation of manufacturing constraints directly into the optimisation, so the result is makeable by the intended process from the start. For casting and moulding, the key constraint is a draw direction: the part must be extractable from the mould, so no internal cavities or undercuts are allowed along that direction. For machining, constraints can impose that every surface be reachable by a cutting tool. For extrusion, the cross-section must be constant. For symmetry and patterning, the design can be constrained to repeat. Each of these restricts the design space and costs some performance relative to the unconstrained optimum, but produces a part that can be made by an established, qualified process. Additive manufacturing has its own constraints, and early claims that it removed manufacturing limits entirely were overstated. Metal powder-bed fusion builds parts layer by layer from a bed of powder melted by a laser or electron beam. Surfaces that overhang too far from the vertical, often beyond roughly forty-five degrees depending on the material and machine, need support structures that must be removed afterwards, which costs time and can damage the surface. Internal cavities must have a way for unmelted powder to escape. Thin features distort with thermal stresses during the build. Andrew Gaynor and James Guest, among others, developed overhang constraints that let topology optimisation produce self-supporting designs, and commercial tools now offer build-direction-aware optimisation as standard. A printed part also has rough as-built surfaces, may contain porosity, and has properties that vary with orientation, all of which affect fatigue strength and must enter the material allowables used in the optimisation. Additive manufacturing also opened a new design dimension: lattices. Instead of solid members, regions of a part can be filled with a repeating cellular structure whose cell type and density vary from place to place. Topology optimisation can be adapted to design graded lattices, assigning a local density that is then realised by a lattice of corresponding thickness. This connects directly to the original Bendsøe and Kikuchi idea of intermediate densities as microstructures, now physically buildable. Where evolution still belongs If gradients dominate topology optimisation, where do evolutionary methods still contribute in structural design? In several places, typically wrapped around or alongside gradient methods rather than replacing them. They are useful for discrete decisions that gradients cannot handle: which of several materials to use, which manufacturing process, how many attachment points, which lattice cell type. Commercial generative design tools effectively run many gradient-based optimisations, one for each combination of material and manufacturing method, and then present the results for comparison, which is a simple exhaustive version of an outer combinatorial search. They are useful for problems where gradients are unavailable or meaningless: crash behaviour, where the response is highly non-linear and chaotic; problems where the evaluator is a black-box commercial code; problems where the objective is noisy. In crashworthiness design, for example, engineers have used evolutionary and surrogate-based methods to tune the shapes and thicknesses of energy-absorbing structures because the simulated response to a small change in design can jump discontinuously as the crumpling pattern changes. They are useful for truss and frame problems with a modest number of discrete members, where the design is a graph of connections rather than a density field, and for problems with several objectives where a Pareto front is wanted. And they are useful at the problem-formulation level: exploring how the optimised design changes as constraints, load weightings and design-space boundaries vary, so the engineer can see which assumptions matter most. The interpretation step The final stage of a topology optimisation is the one most often skipped in descriptions of the method, and it is where much of the engineering lies. The optimiser produces a density field on a mesh. That field must be converted into a geometry, a smooth surface model that can be analysed in detail, documented, toleranced and manufactured. Traditionally this meant an engineer redrawing the result by hand in CAD, interpreting the density field and making judgements about where to smooth, where to thicken, where to round off a junction. Modern tools automate much of this, fitting smooth surfaces to the density field and producing editable geometry directly. But the automated output still needs checking, and the reanalysis of the smoothed geometry frequently reveals stress concentrations or deflections that differ from what the optimisation predicted, because the smoothed shape is not exactly the optimised one and because the detailed analysis uses a finer mesh and more accurate physics. Iterations between optimisation, interpretation and verification are normal. The lesson of topology optimisation for the larger argument of this booklet is twofold. It shows that the choice of search algorithm should follow the structure of the problem; the field's success came from recognising that structural stiffness problems have smooth, cheaply differentiable physics that gradients exploit. And it shows that even the most mature generative method is surrounded by human decisions at every step: the design space, the load cases, the proxy objective, the filter radius, the manufacturing constraints, the interpretation and the verification. The algorithm carves the material. Everything that determines whether the carving is worthwhile happens around it. Chapter 4: Lighter Aircraft and Spacecraft Parts Aerospace has been the natural home of structural optimisation since Lucien Schmit's work in the 1960s, and it remains the industry where generative design delivers its clearest value. The reason is economic before it is technical. In most industries, removing a kilogram from a product saves a little material. In aviation, it saves fuel on every flight for the life of the aircraft, often twenty or thirty years of daily operation, and in spaceflight it saves the cost of launching that kilogram, which is still substantial even after the dramatic falls in launch prices of the past decade. Mass is so valuable that aerospace engineers will accept expensive materials, exotic manufacturing and extended qualification programmes to remove it, which are exactly the costs generative designs tend to bring. Yet the story of generative design in aerospace is not mainly a story about geometry. The algorithms described in the previous two chapters can produce a lightweight bracket in hours. Getting that bracket onto a certified aircraft can take years, and the obstacles are material properties, manufacturing consistency, fatigue behaviour, inspection and regulation. This chapter follows a handful of well-documented cases and then examines the obstacles, because the obstacles show most clearly where engineering judgement now has to live. Why a kilogram is worth so much Aircraft designers speak of the mass snowball. A heavier structure needs more lift, so a larger wing, which is itself heavier; more thrust, so larger engines, which are heavier and burn more fuel; more fuel, which is heavy and must be carried; stronger landing gear to bear it all. In the conceptual design of a new aircraft, each kilogram of unanticipated structural mass can grow into considerably more than a kilogram of total aircraft mass once the design closes. For an existing aircraft whose wing and engines are already fixed, the effect is smaller but still real: a lighter cabin means less fuel burned on every flight, or more payload carried for the same fuel. The economic value of mass varies widely by application and by fuel price, and published estimates differ, so this booklet will not quote a single figure. The qualitative ranking is robust, however. A kilogram saved on a satellite or a launch vehicle upper stage is worth more than one saved on a long-haul airliner, which is worth more than one saved on a regional aircraft, which is worth much more than one saved on a car. This ranking is reflected in where generative design and additive manufacturing have been adopted most aggressively: space hardware and aero-engines first, airframe components next, automotive components mainly where they also deliver other benefits such as part consolidation. Five documented cases Five cases are widely cited and reasonably well documented. Their reported results differ in kind as well as magnitude, and Table 2 sets out what each organisation reported, alongside the source of the claim. Table 2. Selected generative and optimised aerospace and automotive parts, as reported by the organisations involved. Part Organisation, year Reported result Process Source of claim A320 cabin partition Airbus with Autodesk, The Living, APWorks, 2016 45% (30 kg) lighter than existing design Printed Scalmalloy struts Airbus press release, 2016 LEAP engine fuel nozzle tip GE Aviation, mid-2010s 20 parts consolidated into 1; about 25% lighter; about five times more durable Laser powder-bed fusion, cobalt-chrome GE Aviation statements Seat belt bracket (concept) General Motors with Autodesk, 2018 8 parts into 1; 40% lighter; 20% stronger Printed stainless steel GM and Autodesk announcement, 2018 Instrument and payload structures NASA Goddard, 2022 onwards Mass reduced by up to two thirds; design to prototype in about a week Mostly printed metal NASA presentations by R. McClelland Catalyst turboprop engine GE Aviation, late 2010s 855 conventional parts replaced by 12 printed parts Additive manufacturing throughout GE Aviation statements These figures should be read with the caution expressed in the Introduction. Each compares a new part with an existing one, and the existing one was not always designed to the same constraints, for the same manufacturing process, or with the same effort. The comparison mixes the benefits of optimisation, of additive manufacturing, of part consolidation and of a fresh look at the requirements. All four contribute. None of them alone accounts for the headline numbers. The Airbus partition. The partition described in the Introduction was a deliberately ambitious demonstration. The design team began by studying the growth patterns of slime moulds and the structure of mammal bones, then developed algorithms that generated lattices with those characteristics and optimised them against the partition's loads and attachment points. The final design consisted of many separately printed struts and nodes joined together, because the part was too large to print in one piece. Airbus reported the 45 per cent mass reduction and the potential carbon savings across the fleet in its 2016 announcement. The partition was a demonstrator rather than a production part, and its significance was as proof that a large, safety-relevant cabin component could be approached this way and could pass the required load tests. It also illustrates a point the photographs obscure: the bio-inspired algorithm was a choice of representation, a decision that the design space would consist of lattice-like networks, made by the designers before any optimisation began. The GE fuel nozzle. The fuel nozzle tip for the CFM LEAP engine, which powers versions of the Airbus A320neo and Boeing 737 MAX families, is the most famous additively manufactured part in aviation. GE has stated that the printed nozzle replaced an assembly of twenty separately made and brazed parts with one, was about a quarter lighter, and was about five times more durable. Strictly, the nozzle is better described as a case of design for additive manufacturing than of generative design: its internal passages were designed by engineers exploiting the freedom of printing to route fuel and cooling more effectively, rather than by an optimiser. But it matters for this story because it established at scale, in a certified engine produced by the tens of thousands, that printed metal parts could meet aviation's requirements, which opened the path for the more radically optimised parts that followed. In 2015 GE also received approval from the US Federal Aviation Administration for a printed sensor housing in its GE90 engine, widely reported as the first printed part certified for a commercial jet engine. The GM seat bracket. The General Motors bracket, announced in 2018 when the company formed a partnership with Autodesk, is an automotive case but it belongs here because it shows the logic of part consolidation especially clearly. The conventional seat belt bracket was an assembly of eight components. The generative design produced a single printed stainless steel part that GM reported was 40 per cent lighter and 20 per cent stronger. GM presented it as a concept for future vehicles rather than a production part, and the economics of printing steel brackets at automotive volumes remain challenging. Its significance was in showing how the generative workflow handles consolidation: the problem statement specifies the attachment points and loads of the whole assembly, and the optimiser, unconstrained by the boundaries between the old components, finds a single load path. NASA's evolved structures. Ryan McClelland, a research engineer at NASA's Goddard Space Flight Center, has since around 2022 led an effort NASA calls evolved structures: using commercially available generative design software, combined with printing and machining, to produce mounting brackets, instrument structures and other hardware for science missions. NASA reported that the approach could reduce the mass of structural components by up to two thirds while reducing stress, and could take a part from requirements to a prototype in hand in as little as a week, compared with weeks or months for a conventional design and fabrication cycle. Early applications included the EXCITE balloon-borne telescope for observing exoplanet atmospheres, and NASA has listed further uses ranging from space telescopes and planetary instruments to hardware for the Mars Sample Return campaign. McClelland's presentations emphasise a point that bears directly on this booklet's argument: the engineer's work shifts to defining the interfaces, loads and keep-out regions precisely, and the bottleneck moves from drafting to specification and verification. NASA's science hardware also sits in a favourable niche, as Table 2 implies: parts are made in ones and twos, mass is very valuable, and each piece is individually tested. The GE Catalyst engine. GE's Catalyst turboprop, developed in the late 2010s for business aircraft, pushed consolidation to the level of a whole engine. GE stated that additive manufacturing allowed 855 conventionally made parts to be replaced by 12 printed ones, with reductions in mass and improvements in fuel burn. This is again more design for additive manufacturing than generative design in the narrow sense, but it shows where the logic leads: once manufacturing no longer imposes the boundaries between parts, the engineer can state the problem at the level of function, and the number of separate parts becomes an output rather than an input. The real obstacles Each of these cases took years longer to reach service, or never reached it, for reasons that had little to do with the shape. Four obstacles recur. Material allowables. Aerospace structures are designed against statistically derived material properties, the values that a large fraction of all specimens are expected to exceed, with confidence. For conventional alloys made by established processes, these allowables are tabulated in industry handbooks built from decades of testing. For a printed alloy, they depend on the specific machine, powder supply, process parameters, build orientation, heat treatment and surface finishing, and must be established by extensive testing for each qualified process. An optimiser needs these numbers as inputs, and an optimised design with thin members works close to them. If the allowables used in the optimisation are not the ones the qualified process actually achieves, the optimised part has less margin than its analysis shows. Fatigue. Aircraft structures experience millions of load cycles, and many fail by fatigue rather than by a single overload. Fatigue strength is sensitive to surface roughness, porosity and residual stresses, all of which are characteristic weaknesses of printed metal. As-built printed surfaces are rough, and the complex organic geometry of an optimised part makes surface finishing by machining or polishing difficult or impossible in internal regions. A topology optimised for static stiffness, with many slender members and junctions, may have numerous locations where fatigue cracks can begin. Engineers respond by adding fatigue constraints where tools permit, by designing conservatively, by finishing critical surfaces, and above all by testing. Here the gap between the optimiser's proxy objective and the real requirement, described in Chapter 3, has direct safety consequences. Damage tolerance and inspection. Modern aircraft are certified on a damage-tolerance philosophy: structures must be able to carry required loads even with a crack or damage of a specified size, until scheduled inspection finds it. This requires that potential damage be detectable by inspection, and that the structure have alternative load paths so that one failed member does not bring down the whole. An optimised structure that has removed all redundancy to save mass may have a single load path where a conventional design had two. Inspection is also harder: internal lattices and enclosed cavities cannot be examined visually, so printed parts often require computed tomography scanning to verify their internal integrity, which is expensive and limited in resolution for large parts. A problem statement that does not include damage tolerance requirements, such as a constraint that the structure still carries a reduced load with any one member removed, can produce a design that is lighter than any feasible certified design. Process qualification and certification. Regulators such as the US Federal Aviation Administration and the European Union Aviation Safety Agency require that the manufacturing process be shown to produce consistent parts, not merely that one example passes tests. For additive manufacturing, this means controlling and documenting every variable that affects quality, from powder chemistry to machine calibration. The cost of qualifying a new process for a flight-critical part is substantial and is often justified only for parts made in large numbers or with very large benefits. Much of the industry's early printed hardware was therefore secondary structure, brackets and housings whose failure would not endanger the aircraft, while engine and primary structure applications have followed more slowly, with extensive testing. Each of these obstacles corresponds to a piece of knowledge that must enter the generative problem statement if the output is to be certifiable: realistic allowables for the actual process, fatigue behaviour, damage tolerance requirements, inspectability, and manufacturing consistency. When they are left out, the optimiser produces a lighter part than can legitimately be built, and the apparent mass saving shrinks as each missing requirement is added back during detailed design. Some of the gap between the dramatic percentages reported for demonstrators and the more modest savings achieved in certified production parts reflects exactly this process. Consolidation and the supply chain The biggest benefit of generative design in aerospace may not be mass at all. Part consolidation, replacing many components with one, reduces assembly labour, eliminates fasteners and joints (which are common sites of fatigue cracking and corrosion), reduces the number of part numbers an organisation must manage, certify, stock and track, and simplifies the supply chain. GE's emphasis in its descriptions of the fuel nozzle and the Catalyst engine fell as much on these benefits as on mass. Consolidation also has costs. A single complex part that fails or is damaged must be replaced entirely, where an assembly might be repaired by replacing one component. If the printed part is made by one qualified supplier on specific machines, the supply chain may become more fragile rather than less. Spare parts provisioning for an aircraft that will fly for thirty years depends on the manufacturing process and its qualification surviving for thirty years. These considerations are not inputs any current generative design tool asks for. They are part of the judgement that surrounds the tool. Space as the leading edge Spaceflight offers a useful contrast to aviation. Spacecraft are produced in small numbers, sometimes one of a kind, and individual parts are tested extensively before launch. They endure intense but brief loads during launch, and then, in orbit, little mechanical load at all, though thermal cycling and vibration remain important. Mass is extremely valuable. The certification regime is mission-specific rather than the type certification of aviation, and while risk tolerance varies enormously between a crewed vehicle and a small scientific satellite, it is in many cases more permissive of novel processes than commercial aviation. These conditions favour generative design strongly, which is why NASA's evolved structures programme and the extensive use of printed parts in commercial launch vehicles have advanced faster than equivalent airliner applications. In space hardware, the costs of qualification are spread differently, each part is tested individually anyway, and the fatigue lives required are short. The lesson is that how quickly generative design is adopted depends less on the maturity of the algorithms than on how well the surrounding regime of verification can absorb novel geometry. What the cases teach Taken together, the aerospace cases support the controlling idea from an unexpected direction. The algorithms worked in every case; none of these projects was limited by the optimiser's ability to find good shapes. What limited them was the completeness of the problem statement, especially the requirements for fatigue, damage tolerance and inspection that are hard to formulate as optimisation constraints, and the trustworthiness of the inputs, especially material allowables for new processes. The organisations that have moved generative parts into service did so by investing in exactly those areas: testing to establish allowables, process control to ensure consistency, and engineers who understand both the optimisation and the certification basis well enough to formulate problems whose answers can be certified. The geometry, however striking, was the easy part. Chapter 5: Shapes in the Flow When a Shinkansen train enters a tunnel at high speed, it pushes a pressure wave ahead of it down the tube like a piston. At the far end, part of that wave escapes as a sharp pulse that can produce a loud boom audible to people living near the tunnel portal. As Japan's bullet trains grew faster through the 1990s, this tunnel boom became a serious environmental constraint, and much of the visual evolution of Shinkansen noses, from the rounded bullet shape of the 1960s to the long, flattened snouts of later series, is an engineering response to it. For the N700 series, introduced in 2007, JR Central and its partners developed a nose shape they called the "aero double wing", and published descriptions of its development reported the use of computer optimisation with genetic algorithms, evaluating candidate shapes with fluid dynamics simulation, to reduce the pressure wave and aerodynamic drag while meeting constraints such as the space needed for the driver's cab. The N700 nose illustrates the central difficulty of aerodynamic generative design. The objective is defined by fluid flow, and computing fluid flow around a complex three-dimensional shape is expensive. A structural analysis of a bracket might take seconds or minutes. A high-fidelity flow simulation of a wing or a train nose can take hours on a computing cluster, and each candidate shape needs at least one. An optimiser that needs thousands of evaluations cannot afford the most accurate simulations, and an optimiser that uses cheap simulations risks optimising what those simulations get wrong. Everything about aerodynamic shape optimisation is shaped by this economy. Describing a shape Before any search can begin, the shape has to be described by a manageable number of variables, and in aerodynamics this choice, the parameterisation, matters more than in almost any other domain. The difficulty is that aerodynamic performance is sensitive to small features. The drag of a transonic wing depends on the strength of the shock wave on its upper surface, which depends on the curvature of the surface to fractions of a per cent of the chord. A parameterisation that cannot represent subtle curvature changes cannot find a good wing. Yet a parameterisation with too many variables makes the search expensive and can produce unrealistic, wavy surfaces. Engineers have developed many schemes, each with characteristic strengths. Raymond Hicks and Preston Henne, working at NASA in the 1970s, proposed adding smooth bump functions to a baseline aerofoil, each bump's height being a design variable; this produced realistic modifications and is still used. Spline curves and surfaces, controlled by a grid of control points, are the native language of CAD and can describe almost any smooth shape. Brenda Kulfan at Boeing developed the class-shape transformation method, published in 2008, which separates a generic class of shape, such as a round-nosed aerofoil with a sharp trailing edge, from a shape function described by a few coefficients, so that even with few variables every shape produced is aerodynamically plausible. For three-dimensional shapes, free-form deformation has become especially important. Introduced for computer graphics by Thomas Sederberg and Scott Parry in 1986, it embeds the geometry in a lattice of control points, like a shape set inside a block of jelly. Moving the control points deforms the block and everything inside it smoothly. This lets the optimiser modify a complex existing geometry, such as a wing with a fuselage junction and a nacelle, without needing to know its underlying CAD description, and it works naturally with the computational mesh used for flow simulation, which can be deformed along with the shape. The choice of parameterisation embodies assumptions about what good designs look like. A parameterisation built around a baseline design will find improvements near that baseline. One built around a generic class will find good members of that class. Neither will find a radically different concept. This is the representation principle of Chapter 2 in its sharpest form: the optimiser can only discover what the parameterisation allows it to express, and the person who chooses the parameterisation has already made the most important design decision. Gradients again: the adjoint revolution The economics of aerodynamic optimisation changed decisively when Antony Jameson, in a 1988 paper, showed how to apply the adjoint method from control theory to the equations of fluid flow. As in the structural case described in Chapter 3, the adjoint method computes the sensitivity of an objective such as drag to every design variable at a cost roughly equal to one additional flow solution, regardless of how many design variables there are. A wing described by hundreds of free-form deformation control points could thus be optimised with gradients at a cost of a few hundred flow solutions in total, instead of the hundreds of thousands an evolutionary method might need for so many variables. Adjoint-based optimisation has since become the standard tool for detailed aerodynamic design of wings and other aircraft surfaces. A well-known benchmark is the common research model wing, a representative modern transonic airliner wing defined for research purposes. Zhoujie Lyu, Gaetan Kenway and Joaquim Martins published a study in the AIAA Journal in 2015 that optimised this wing's shape with hundreds of design variables, using a high-fidelity flow solver and an adjoint method, and reported substantial drag reductions at the design condition. They also investigated whether the problem had multiple local optima, starting the optimisation from different initial wing shapes, and found that the results converged to very similar designs, suggesting that for this kind of problem the landscape is far less rugged than one might fear. That finding matters for algorithm choice: if the landscape is smooth and close to having a single optimum, the main argument for evolutionary methods, their ability to escape local optima, carries little weight, and gradients win on efficiency. Where evolution keeps its place Evolutionary methods nonetheless retain an important role in aerodynamics, in precisely the circumstances the general analysis of Chapter 2 predicts. They are used when there are several competing objectives and the designer wants the whole trade-off front. The N700 nose had at least two aerodynamic objectives, the tunnel pressure wave and drag, along with practical constraints; wings trade drag against structural weight and the size of fuel tanks; turbine blades trade efficiency against noise and structural loads. Multi-objective evolutionary algorithms produce trade-off fronts naturally, which is why Obayashi's group in Japan and many others adopted them for aircraft and vehicle design problems from the late 1990s. They are used when the design involves discrete or topological choices: the number of blades on a fan, whether to add a winglet, the arrangement of components on a vehicle. They are used when flow features change discontinuously as the shape changes, for example when a flow separation jumps from one location to another, which makes gradients unreliable. And they are used in early conceptual design, where cheaper, lower-fidelity evaluators are acceptable and the goal is to explore widely rather than refine precisely. In practice, the most effective approaches often combine methods: an evolutionary or other global search over a low-dimensional description with a cheap evaluator to find the right region and concept, followed by adjoint-based refinement with a high-fidelity evaluator to polish the details. Surrogates: spending evaluations wisely When neither evolutionary search nor adjoint gradients are practical, because the evaluator is too expensive for the former and provides no gradients for the latter, surrogate models offer a third way. A surrogate is a cheap mathematical approximation of the expensive evaluator, built from a modest number of real evaluations. The optimiser searches the surrogate, which costs almost nothing, and periodically checks promising candidates with the real evaluator, adding the results to the surrogate's training data and improving it where it matters. The most widely used surrogates in engineering design are Gaussian process models, known in geostatistics and engineering as kriging. Their great advantage is that they predict not only a value but also an uncertainty for that prediction: confident near designs that have been evaluated, uncertain far from them. This permits a principled answer to the question of where to evaluate next. Donald Jones, Matthias Schonlau and William Welch formalised this in 1998 as efficient global optimisation, choosing the next evaluation where the expected improvement over the best design so far is greatest, which balances exploiting regions predicted to be good with exploring regions where uncertainty is high. This approach, now usually called Bayesian optimisation, can find good designs in tens or a few hundreds of expensive evaluations, provided the number of design variables is modest, typically below twenty or thirty. The textbook by Alexander Forrester, András Sóbester and Andy Keane, Engineering Design via Surrogate Modelling, published in 2008, remains a clear practical guide. Surrogates carry their own version of the exploitation problem. An optimiser searching a surrogate will be drawn toward regions where the surrogate is optimistically wrong. Bayesian optimisation guards against this partly by design, since it represents uncertainty explicitly, and by always confirming candidates with the true evaluator before trusting them. Surrogates without honest uncertainty estimates, including many neural network surrogates, require more care, as Chapter 7 discusses. Fidelity as a design choice Aerodynamicists have a ladder of evaluators, and much of the craft of aerodynamic optimisation lies in deciding which rung to stand on at each stage. At the bottom are panel methods and vortex-lattice methods, which treat the flow as inviscid and represent the wing by a distribution of singularities on its surface or camber line. They run in seconds, capture lift and the induced drag that comes from the wing's span loading remarkably well, and know nothing about shock waves or boundary layers. Above them are solutions of the Euler equations, which capture shocks but still ignore viscosity, then the Reynolds-averaged Navier-Stokes solutions used for most detailed design, and at the top scale-resolving simulations and, ultimately, the wind tunnel and flight test. Each rung is perhaps one or two orders of magnitude more expensive than the one below it, and each is trustworthy for a different set of questions. A sensible generative process uses the cheap rungs where they are reliable and climbs only when the question requires it. In the conceptual design of an aircraft, wing span, sweep and planform area can be explored with vortex-lattice methods and empirical drag estimates across thousands of candidates, because the trade-offs between induced drag, structural weight and fuel volume are captured adequately at that level. The detailed shaping of aerofoil sections to control a transonic shock requires the higher rungs. Multi-fidelity methods try to combine the rungs within a single optimisation. The idea, formalised for surrogate modelling by Marc Kennedy and Anthony O'Hagan in a 2000 paper in Biometrika, is to use many cheap low-fidelity evaluations to learn the general shape of the landscape and a few expensive high-fidelity evaluations to learn the correction between the two. If the cheap and expensive evaluators disagree in a systematic way, a model of the disagreement can be learned from a handful of paired evaluations. This can reduce the number of expensive evaluations needed considerably, provided the low-fidelity evaluator captures the trends correctly. Where it does not, for instance because a cheap inviscid method cannot see the flow separation that dominates a particular design, the multi-fidelity model inherits its blindness, and the optimiser is guided confidently in the wrong direction. There is a further complication. Aerodynamics rarely acts alone. A wing bends and twists under load, which changes its aerodynamic shape, which changes the load. Optimising the wing's aerodynamic shape while ignoring its structure tends to produce long, thin, highly loaded wings that are aerodynamically superb and structurally impractical, because the structural weight needed to carry them is not counted. Multidisciplinary design optimisation couples the aerodynamic and structural evaluators so that the optimiser sees both at once. Joaquim Martins and Andrew Lambe surveyed the many ways of organising such coupled optimisations in a 2013 review in the AIAA Journal, and the coupled aerostructural optimisation of wings, with adjoint gradients computed through both disciplines together, has become a mature research capability. The lesson again concerns the problem statement. An aerodynamic optimisation that excludes structure is not wrong, but it answers a narrower question than the one the aircraft designer needs answered, and the answer will be pushed precisely in the direction the missing discipline would have resisted. The evaluator's blind spots Even the most expensive flow simulations used in industrial optimisation are approximations. Nearly all practical aerodynamic optimisations solve the Reynolds-averaged Navier-Stokes equations, which do not resolve the chaotic eddies of turbulence directly but represent their average effect through a turbulence model. Turbulence models are calibrated on flows of certain kinds, attached boundary layers and mild pressure gradients, and are known to be less reliable in others, particularly flows with significant separation, strong curvature or transition from smooth laminar flow to turbulence. An optimiser does not know any of this. If a turbulence model underestimates drag for a particular kind of surface curvature, the optimiser will be rewarded for producing that curvature. Experienced practitioners have learned to recognise symptoms: unexpectedly wavy surfaces, extreme local curvature, designs whose improvements are concentrated in regions of flow the turbulence model handles poorly. They verify optimised designs with higher-fidelity simulations, scale-resolving methods that capture more of the turbulence directly at much greater cost, and ultimately with wind tunnel tests. Mark Drela of the Massachusetts Institute of Technology wrote a short paper in 1998, "Pros and Cons of Airfoil Optimization", which remains one of the clearest statements of a related trap. He showed that an aerofoil optimised for one specific flight condition tends to exploit that condition, producing small surface features that improve performance exactly at the design point while degrading it, sometimes badly, at nearby conditions. A real aircraft flies at a range of speeds, altitudes and weights, so a point-optimised design is a poor design. The remedy is multipoint optimisation: optimising a weighted combination of performance across several conditions, or constraining performance at off-design conditions. But which conditions to include, and with what weights, is a judgement about how the aircraft will actually be used. Drela's point was that the optimiser produces precisely what the problem statement requests, and that a problem statement capturing a single point of a continuous operating envelope will produce a design that is fragile everywhere else. The same principle applies to robustness to manufacturing variation. A wing optimised to the last fraction of a millimetre may lose much of its advantage once real manufacturing tolerances, surface roughness, paint and contamination from insects are accounted for. Robust design optimisation, which evaluates designs across a distribution of possible variations rather than at a single nominal shape, addresses this at the cost of many more evaluations, which brings the problem back to the economy of the evaluator. Beyond aircraft The same methods and the same lessons apply wherever shapes interact with fluids. Wind turbine blades are optimised for energy capture across a range of wind speeds, subject to structural loads, noise and transport constraints, often with multi-objective evolutionary methods at the conceptual stage and gradient methods for detailed aerodynamic shaping. Car bodies are shaped for drag with growing attention as electric vehicles make range directly sensitive to aerodynamics, though styling, packaging and safety constrain them heavily. Turbomachinery blades, heat exchanger fins, ship hulls and the internal passages of pumps and valves have all been subject to optimisation, and in many of these the combination with additive manufacturing allows internal flow passages of shapes that could not previously be built. In each, the generative process is only as good as three choices: the parameterisation, which bounds what can be found; the evaluator and its fidelity in the region where the optimiser goes; and the set of operating conditions and variations against which the design is judged. The N700's nose worked because its designers chose a representation that could express a long, sculpted, double-curved form, evaluated it against the phenomenon that actually mattered, the tunnel pressure wave, and verified the result through extensive testing before the train entered service. The genetic algorithm was a means of searching the space those choices defined. It was not the reason the space contained a good answer. Chapter 6: Buildings as Thermal Machines A building is, among other things, a thermodynamic device. It sits in a climate that heats it with sunshine and cools it with wind and night sky; it contains people, lights and equipment that release heat; it exchanges air with the outside through openings and leaks; it stores heat in its mass and releases it hours later. Its heating, cooling, ventilation and lighting systems spend energy to keep the interior within the narrow range of conditions people find comfortable, and how much energy they spend depends overwhelmingly on choices about the building itself: its shape, its orientation, the proportion and placement of glass, the shading, the insulation, the mass. The United Nations Environment Programme's Global Status Report for Buildings and Construction, published annually, has for several years attributed roughly a third of global energy-related carbon dioxide emissions to the buildings sector, counting both the operation of buildings and the production of their materials. Much of the operational share is decided early. The decisions that most affect a building's lifetime energy demand, its massing, orientation and window ratios, are typically fixed in the first weeks of design, when information is scarce, and are expensive to revisit afterwards. Detailed energy modelling, where it happens at all, has traditionally come later, as a compliance check on a design that is already largely settled. Generative design promises to reverse this sequence, bringing performance analysis into the earliest decisions and letting it shape the form rather than merely grade it. Buildings are also the domain in which the gap between what the evaluator predicts and what actually happens is largest, which makes them the most demanding test of the argument of this booklet. The evaluators The core evaluator for building thermal performance is whole-building energy simulation. The most widely used engine is EnergyPlus, developed for the US Department of Energy from the late 1990s and first released in 2001, which simulates a building's heat balance hour by hour, or at finer intervals, across a whole year of weather data. It models heat conduction through walls and roofs, solar gains through windows, internal gains from occupants and equipment, air exchange, thermal storage in the building's mass, and the operation of heating, ventilation and air-conditioning systems. The inputs are extensive: geometry, construction materials, window properties, occupancy and equipment schedules, temperature setpoints, system types and efficiencies, and a weather file representing a typical year for the site. Daylight is evaluated separately, usually with Radiance, a physically based lighting simulation program developed by Greg Ward at Lawrence Berkeley National Laboratory from the late 1980s. Climate-based daylight metrics compute, across the hours of a year, how much of a floor area receives useful daylight levels, how often direct sun causes glare, and how much electric lighting can be saved. Other evaluators cover thermal comfort, natural ventilation (sometimes with fluid dynamics simulation, at much greater cost), solar exposure of outdoor spaces, and embodied carbon in the building's materials. For generative design, what matters is that these engines could be connected to parametric geometry. In 2013 Mostapha Sadeghipour Roudsari and Michelle Pak presented Ladybug, a set of Grasshopper components that brought climate data analysis into the parametric environment, and its companion Honeybee connected Grasshopper geometry to EnergyPlus and Radiance. An architect could now build a parametric model of a building, connect it to energy and daylight simulation, and wire the results to an evolutionary solver such as Galapagos or a multi-objective one such as Octopus or Wallacei. Each candidate design would be generated, simulated for a year, scored, and fed back to the solver. A single annual energy simulation of a simple building model takes seconds to a few minutes, and a daylight simulation a similar amount, which puts evolutionary search within reach. Running a few thousand simulations overnight on a workstation, or in parallel on a computing cluster, is practical. This is why evolutionary algorithms are far more prominent in building performance optimisation than in structural topology optimisation: the design variables are few (tens rather than millions), mixed (continuous dimensions alongside discrete choices of construction type or glazing product), and the evaluators are black boxes that provide no gradients. All the conditions that favour evolution, as Chapter 2 described them, are present. A 2014 review by Anh-Tuan Nguyen, Sigrid Reiter and Philippe Rigo in Applied Energy surveyed simulation-based optimisation in building performance analysis and found that genetic algorithms and other evolutionary methods were the most commonly used approaches. What gets optimised The design variables in building performance optimisation fall into a few groups, and their effects pull in different directions, which is what makes the problem genuinely multi-objective. Table 3 summarises the typical trade-offs for the most commonly optimised variables. Table 3. Common building design variables and the trade-offs they create. Variable Heating demand Cooling demand Daylight Typical tension Window-to-wall ratio Rises with more glass in cold climates, partly offset by solar gain Rises with more glass Improves, then glare Daylight and views against heat loss and overheating Orientation Sun-facing glazing can reduce it Unprotected west glazing raises it Varies by facade Solar gain useful in winter, harmful in summer External shading depth Can rise by blocking winter sun Falls Falls Summer protection against winter gain and daylight Building compactness Falls as exposed surface shrinks Mixed Falls in deep plans Low heat loss against daylit, ventilated floors Thermal mass Falls with useful solar gain Falls with night ventilation No direct effect Benefits depend on climate and operation The table is deliberately qualitative, because the magnitudes depend heavily on climate, building type and use. That dependence is itself the point. A rule of thumb that holds in a cold, sunny climate fails in a hot, humid one. Optimal window ratios, shading depths and orientations differ between an office, where internal heat from people and computers is large, and a dwelling, where it is small. A generative process run against the actual climate file and the actual use pattern can find combinations that no general rule would suggest, and can show the shape of the trade-offs: how much daylight is lost for each step reduction in cooling energy, where the curve flattens. The objectives themselves need careful choice. Annual energy use per square metre is common and simple. But energy is not carbon, since the carbon intensity of electricity and of gas differ and vary with time; carbon is not cost; and neither captures comfort. A building that uses little energy because it is often uncomfortably warm has not succeeded. Hours outside a comfort range, or a comfort metric that accounts for the adaptive expectations of occupants in naturally ventilated buildings, often enter as objectives or constraints. And as operational energy falls, embodied carbon, the emissions from producing the concrete, steel, glass and insulation, becomes a larger share of the building's lifetime total. Thicker insulation reduces operational energy but adds embodied carbon, and at some point the trade turns negative. Whole-life carbon optimisation, which includes both, can find different optima from energy optimisation alone. An early-stage study, step by step It helps to walk through how a generative performance study typically unfolds on a real project, because the sequence shows where the decisions lie. Consider a mid-sized office building on an urban site in a temperate climate with warm summers and cool winters, at the stage where the architects have a site, a brief for floor area, and a handful of sketch massings. The team first builds a parametric model whose variables are those decisions still open: the orientation of the long axis, the depth of the floor plate, the number of storeys within the permitted height, the window-to-wall ratio on each façade separately, the depth of horizontal shading on the south and of vertical fins on the east and west, and a choice among three or four glazing products with different solar and thermal properties. That is perhaps a dozen variables, several of them discrete. Everything else, the wall and roof constructions, the occupancy schedules, the setpoints, the ventilation strategy, is fixed at assumed values for now, which is already a judgement: the team is choosing what to optimise and what to hold constant. The evaluator is an energy simulation of a simplified version of each candidate, with one thermal zone per façade orientation and a core zone on each floor, together with a daylight simulation on a sample floor. The objectives are annual energy demand for heating, cooling and lighting combined, the fraction of floor area with adequate daylight for most working hours, and an approximate construction cost for the envelope. A multi-objective evolutionary solver runs a few thousand candidates. What comes back is not a building but a trade-off surface. Typically it shows that a band of orientations is clearly better than others and that deep floor plates sacrifice daylight for little energy gain, which lets the team rule out large regions of the design space with confidence, since those conclusions rest on robust physics. It shows how energy demand rises as glazing increases on each façade, and that the rise is steepest on the west, where low afternoon sun is hardest to shade. It shows that shading depth and glazing product can partly substitute for one another, so that a higher-performance glass permits shallower fins at extra cost. Then the team interrogates the result. They rerun a selection of designs from different parts of the front with different occupancy assumptions, a higher equipment load, a warmer future weather file and a less airtight envelope, to see whether the ranking holds. Where the ranking is stable, they proceed with confidence. Where it shifts, they know the decision depends on assumptions they must either pin down with the client or design to be robust against. The eventual choice of massing and glazing is made by the architects, weighing the performance trade-offs against urban context, views, structure and the client's priorities, none of which the solver saw. The generative study did not design the building. It replaced a set of guesses about performance with a map of consequences, which is the most an early-stage evaluator can honestly offer and a great deal more than most buildings ever receive. From buildings to sites and floor plans Generative methods in architecture extend well beyond the thermal envelope. At the urban scale, tools emerged during the 2010s that generate and evaluate many site layouts, building massings and arrangements simultaneously, scoring them on sunlight access, views, noise, wind comfort, density and other criteria. Spacemaker, a Norwegian start-up founded in 2016, built a platform for this kind of early-stage site analysis; Autodesk acquired it in 2020 and later developed it into its Forma product. These tools emphasise rapid, approximate evaluation, many options and interactive steering by the designer, which places them closer to the exploratory mode of generative design described in Chapter 1 than to precise optimisation. At the scale of the floor plan, generative design has been applied to space planning. In a project known as Project Discover, Autodesk's research group designed the layout of its own new office in Toronto's MaRS Discovery District, described in a 2017 paper by Danil Nagy and colleagues. The team surveyed employees about their working preferences, then formulated objectives including adjacency to preferred colleagues and teams, work style preferences, access to daylight and views, and a measure of how much activity, a "buzz", common areas would attract. A genetic algorithm generated and evaluated thousands of layouts within a parametric model, and the designers explored the resulting trade-off front before choosing and refining a design. The project is instructive less for its outcome than for how much of its effort went into deciding what to measure, a task that required ethnographic work with future occupants rather than any computation. The performance gap Every evaluator in this booklet is an approximation, but building energy simulation sits further from reality than most, for a reason that is fundamental rather than technical. A wing's performance depends on physics. A building's energy use depends on physics and on people. How occupants set thermostats, open windows, draw blinds, leave lights on, use equipment and occupy spaces varies enormously, and these behaviours drive energy use as much as the building fabric does. Construction quality adds further variation: insulation installed with gaps, thermal bridges at junctions, air leakage through poorly sealed joints. Commissioning and operation of systems vary. And the weather in any actual year differs from the typical year used in simulation. The result is the well-documented performance gap between predicted and measured energy use. Pieter de Wilde reviewed the phenomenon in a 2014 paper in Automation in Construction, drawing on studies in which measured consumption frequently differed substantially from design predictions, often exceeding them by large margins. The gap has multiple causes, but its existence alone has important implications for generative design. First, it means the absolute values of predicted energy use are unreliable, so optimisation is meaningful mainly for comparing designs relative to one another, under the assumption that errors affect all candidates similarly. That assumption holds for some errors, such as a uniformly wrong estimate of equipment loads, but not for others. If occupants in reality draw blinds whenever there is direct sun on their desks, a design optimised for solar gain will receive less of it than predicted, while one that relies on insulation will not be affected. The ranking can change. Second, optimisation actively exploits the assumptions most likely to be wrong. An optimiser told that occupants will open windows for natural ventilation exactly when the indoor temperature exceeds a threshold will design a building that depends on that behaviour. An optimiser given an optimistic airtightness value will find that adding more glazing costs less than it does in reality. The general principle from Chapter 2, that optimised designs sit disproportionately where the evaluator errs in their favour, applies here with the full force of human unpredictability added to physical approximation. Third, it argues for robustness as an objective. A design that performs well across a range of occupant behaviours, construction qualities and weather years is more valuable than one that performs best under nominal assumptions and poorly under realistic variation. Robust optimisation in building design runs each candidate under multiple scenarios, sampled distributions of uncertain inputs, and optimises for average performance, worst-case performance, or some combination. Future climate is a particularly important uncertainty: a building designed today will operate through decades of warming, and optimising against historical typical weather may produce designs that overheat later in their lives. Weather files representing projected future climates exist and can be included as additional scenarios. The performance gap also shifts the value of generative methods toward the decisions least sensitive to the most uncertain inputs. Massing, orientation and window ratio, which affect performance through relatively robust physical mechanisms such as solar geometry and surface-to-volume ratio, are better candidates for optimisation than systems control strategies, which depend heavily on operation. Experienced practitioners use generative tools to rule out poor configurations and to understand trade-offs at the early stage, rather than to declare a single optimal design with confidence its evaluator cannot support. Thermodynamics and form Is there anything distinctive in what generative methods produce for buildings? The organic forms of structural topology optimisation have no real equivalent here, partly because building design spaces are usually parameterised conservatively, in terms of conventional elements such as windows, shading devices and rectangular volumes, and partly because the thermal objectives are relatively insensitive to fine geometric detail. A generated building more often looks like a well-proportioned conventional building than like something grown. The more distinctive results appear in façades, where the geometry of shading elements can be tuned panel by panel to the sun path on each face of the building, producing variation that appears ornamental but is functional. Fins and louvres that deepen on the west face and flatten on the north, perforations whose density varies with solar exposure, and kinetic shading that adjusts through the day are typical. The Al Bahar Towers in Abu Dhabi, completed in 2012 with a façade of motorised, umbrella-like shading units that open and close with the sun, are often cited as an example of computationally designed responsive shading, though the design process involved conventional parametric design and analysis rather than generative search. This modest visual signature reinforces the argument. What makes generative building design valuable is not new forms but better-informed decisions about familiar ones, made early enough to matter, against objectives chosen with care, by designers who understand how far to trust the simulations. The tools make it possible to see in an afternoon how energy, daylight, comfort and carbon trade against one another across thousands of variants. Choosing what to measure, how to account for the people who will occupy the building, and how much confidence to place in the results remains the architect's and the engineer's work, and in buildings more than in any other domain, that work determines whether the optimisation means anything at all. Chapter 7: Learning to Evaluate, Learning to Generate For most of its history, generative design meant coupling a search algorithm to a physics simulation. The algorithm knew nothing about engineering; the simulation knew physics but nothing about what had been designed before. Machine learning, and especially the deep learning that transformed image and language processing in the 2010s and 2020s, offers to change both sides of that arrangement. Neural networks trained on simulation results can stand in for the simulation, predicting performance in milliseconds instead of hours. Neural networks trained on existing designs can propose new geometry directly, without iterative search. And since around 2023, systems that generate editable CAD models from sketches or text descriptions have moved from research papers toward commercial products. These developments are real and important, and they are also widely misunderstood. This chapter separates the two roles machine learning plays, as evaluator and as generator, and examines what each changes and what each leaves untouched. The short answer is that machine learning dramatically changes the cost of the generative loop but not its structure. A learned evaluator is still an evaluator, with a domain of validity that optimisation will push against. A learned generator still needs a problem statement, and it adds a new dependency: on the designs it was trained on. Learned evaluators The most mature use of machine learning in generative design is the surrogate model, the cheap approximation of an expensive evaluator introduced in Chapter 5. Classical surrogates such as Gaussian processes work well for problems with tens of variables. Neural networks extend the idea to much richer inputs. Instead of predicting drag from a dozen shape parameters, a neural network can take an entire three-dimensional geometry, represented as a surface mesh, a point cloud or a grid of voxels, and predict drag, or even the full pressure and velocity fields around it. Several architectures have proved useful. Convolutional networks, borrowed from image processing, work on geometries represented as regular grids. Graph neural networks operate directly on meshes, passing information between neighbouring nodes in a way that mirrors how physical quantities propagate between neighbouring regions; a 2021 paper from DeepMind by Tobias Pfaff and colleagues, introducing a model called MeshGraphNets, showed that such networks could learn to simulate a range of physical systems, from fluid flow to cloth, at a fraction of the cost of the original simulators. Neural operators, such as the Fourier neural operator introduced by Zongyi Li and colleagues in 2021, learn mappings between entire functions, such as from a boundary shape to a flow field, and can generalise across mesh resolutions. Commercial tools built on these ideas have emerged. Neural Concept, a company spun out of the Swiss Federal Institute of Technology in Lausanne, offers geometric deep learning surrogates for engineering simulation, and has reported work with automotive and aerospace firms. PhysicsX, founded in London in 2023, builds what it describes as AI models for physics simulation in engineering. Major simulation software vendors have added machine learning surrogates to their own products. The promise in every case is the same: train a model on a few hundred or a few thousand simulations of designs in a family, and then evaluate new designs in that family almost instantly, so that an engineer can explore interactively, or an optimiser can run tens of thousands of evaluations, at negligible cost. A related idea, physics-informed neural networks, introduced by Maziar Raissi, Paris Perdikaris and George Karniadakis in a 2019 paper in the Journal of Computational Physics, trains networks to satisfy the governing equations directly, rather than learning only from simulation data. They have attracted enormous research attention. For routine forward simulation, solving the flow around a given shape, they have generally not proved faster or more accurate than established numerical methods, and their main value has been in inverse problems and in combining sparse measurements with physical laws. Readers encountering claims that physics-informed networks will replace conventional simulation in design should treat them cautiously. The domain of validity A neural surrogate is trained on a particular set of designs. Within the range those designs cover, it can be remarkably accurate. Outside it, a neural network gives no warning: it produces a confident prediction that may be wildly wrong. Unlike a Gaussian process, a standard neural network does not report how uncertain it is. This is exactly the condition under which optimisation is most dangerous. As Chapter 2 explained, an optimiser drifts toward wherever the evaluator's errors favour it, and the largest errors of a learned surrogate are found outside its training data. An optimiser coupled to a neural surrogate will, unless prevented, wander out of the training distribution into regions where the surrogate predicts implausibly good performance, and return a design that is excellent according to the surrogate and ordinary or worse according to physics. Practitioners use several defences. They constrain the optimisation to stay within the training distribution, which limits how novel the result can be. They estimate uncertainty, for example by training an ensemble of networks and treating disagreement among them as a sign of unreliability, and penalise designs where uncertainty is high. They use active learning: periodically running the true simulation on the most promising candidates, adding those results to the training data, and retraining, so that the surrogate becomes accurate precisely where the optimiser wants to go. This last approach is essentially the Bayesian optimisation strategy described in Chapter 5, scaled up to richer geometry. In every case, final designs are verified with the true simulation and, where stakes are high, with physical tests. The economic effect of learned evaluators is therefore real but conditional. They make it cheap to search a design family that has already been simulated extensively. They do not make it cheap to discover something genuinely outside what was simulated, because any such discovery must be checked by the expensive evaluator anyway. An organisation that has spent years simulating variants of a product line has a valuable training set, and can explore that family far faster than before. A team approaching a new problem has to generate the data first. Learned generators The second role for machine learning is generating geometry directly. The deep generative models that produced the explosion of AI image generation, variational autoencoders, generative adversarial networks and especially diffusion models, can be trained on engineering designs instead of photographs, and can then sample new designs that resemble the training set. Early work applied these models to topology optimisation. Researchers trained networks on large sets of topology-optimised structures, each paired with its loads and boundary conditions, and asked the network to predict the optimised structure for new loading conditions in a single pass, without running the iterative optimisation. A 2019 paper by Sangeun Oh and colleagues in the Journal of Mechanical Design combined topology optimisation with generative adversarial networks to produce diverse wheel designs. In 2023 François Mazé and Faez Ahmed of the Massachusetts Institute of Technology presented TopoDiff, a diffusion model for topology optimisation, at the AAAI conference, under the title "Diffusion models beat GANs on topology optimization". It conditioned generation on the loads and boundary conditions and used guidance from auxiliary models to steer samples toward low compliance and away from disconnected, unmanufacturable structures. They reported that it produced far fewer infeasible designs and better performance than earlier generative adversarial approaches. These results are genuine advances, and they also reveal the limits of the approach. A 2022 review by Lyle Regenwetter, Amin Heyrani Nobari and Faez Ahmed in the Journal of Mechanical Design, surveying deep generative models across engineering design, observed that many published models were evaluated mainly by how similar their outputs looked to the training data, rather than by whether those outputs met engineering requirements, performed well, or were feasible to make. A generative model trained on existing designs learns to produce designs like the existing ones. That is useful for speed, since it produces in a second what optimisation would take an hour to compute, but it is not a source of designs better than those in the training set, unless performance is explicitly built into the generation process. The authors argued for evaluating generative models on design performance, constraint satisfaction, novelty and diversity together. There is a deeper point here about the relationship between learning and optimisation. An optimiser driven by physics can, in principle, find something no one has built, because it responds to the physics rather than to precedent. A generator driven by data reproduces, interpolates and recombines precedent. Each has its place. Many of the most promising current approaches combine them: a generative model provides a compact, well-behaved space of plausible designs, its latent space, and an optimiser, often evolutionary, searches that space against a physics-based or learned evaluator. The generative model supplies the representation, the optimiser supplies the search, and the evaluator supplies the judgement of quality, which is the same four-part structure described in Chapter 1, with machine learning occupying some of the slots. A related family of methods, quality-diversity algorithms such as MAP-Elites, introduced by Jean-Baptiste Mouret and Jeff Clune in 2015, rejects the goal of a single optimum altogether. These methods search for the best design in each cell of a grid defined by descriptive features, such as the best-performing design of each overall size and shape type, producing an archive of diverse, high-performing options. For the exploratory mode of generative design, where the designer wants to understand the range of possibilities rather than receive one answer, they are especially well suited, and they have been combined with surrogate models and generative networks in research on aerodynamic and architectural design. Generating CAD A persistent frustration with generative design, described in Chapter 3, is the interpretation step: optimisers produce density fields or meshes, while engineering runs on parametric CAD models built from features such as sketches, extrusions, fillets and holes, which can be edited, dimensioned and toleranced. A generated mesh is a dead end in a workflow that expects editable features. A line of research has addressed this by teaching networks to generate CAD models as sequences of modelling operations, the way a human engineer builds them. Large public datasets made this possible: the ABC dataset, released in 2019 by Sebastian Koch and colleagues, collected about a million CAD models from public sources, and Autodesk's Fusion 360 Gallery dataset, described by Karl Willis and colleagues in 2021, recorded the actual sequences of operations designers used. DeepCAD, presented by Rundi Wu, Chang Xiao and Changxi Zheng in 2021, trained a model to generate sequences of sketch and extrude commands that produce valid, editable CAD models. Since 2023, these ideas have converged with large language models. Language models can write code, and several CAD systems can be driven by code, such as the open-source CadQuery and OpenSCAD, so a language model can generate a CAD model by writing the program that builds it. Start-ups have launched text-to-CAD services that produce parametric models from written descriptions, and major vendors have announced foundation models trained on CAD data. Autodesk, at its annual conference in September 2025, announced what it called neural CAD, generative models intended to produce and edit CAD geometry and building designs from prompts, sketches and other inputs within its Fusion and Forma products. As of late 2026 these capabilities are developing quickly, and their strengths are clearest for routine parts: brackets, enclosures, plates with patterns of holes, the large volume of ordinary geometry that consumes much of a designer's day. It is worth being precise about what text-to-CAD is and is not. It is a powerful new interface for producing geometry, and it may well remove much of the drudgery of CAD modelling. But a text prompt is a problem statement, and usually a very incomplete one. "A bracket to mount a 2 kg sensor to a 40 mm tube" omits the loads, the vibration environment, the material, the manufacturing process, the clearances and the standards. A system that produces a plausible bracket from that prompt has filled the gaps with defaults learned from its training data, which is to say with the conventions of past brackets. For many purposes that is exactly right. For any part where the specific conditions matter, the conventions must be checked against the actual requirements, and the engineer must know what those requirements are. The interface has changed; the obligation has not. The data problem Machine learning in engineering faces a constraint that image and language models largely escaped: data. Engineering designs, and especially the simulation and test results that say how well they perform, are mostly proprietary. Companies hold them as competitive assets and are often legally obliged to protect them, for example under export controls in aerospace and defence. Public datasets exist but are small compared with the billions of images and documents that trained general-purpose models, and they skew toward simple or hobbyist parts. This shapes how machine learning is being adopted. Large organisations with extensive internal simulation archives can train surrogates and generators on their own data, gaining an advantage that smaller firms cannot easily match. Vendors offer models pre-trained on general geometry that customers fine-tune on their own designs. And synthetic data generation, running large numbers of simulations specifically to train models, has become a significant activity in itself, which brings back the cost of the expensive evaluator that the surrogate was meant to avoid, now paid in advance. The data problem also has a subtler consequence. A model trained on an organisation's past designs encodes that organisation's past assumptions, including its conservatism, its habits and its mistakes. If past designs were systematically over-built in some direction because of a load case later found unnecessary, the model will learn to over-build. If a failure mode was never encountered because previous designs were conservative, the model has no data showing what happens near it. Learned generators are a form of institutional memory, and like all institutional memory they need to be questioned as well as used. What changes and what does not Machine learning changes the economics of generative design profoundly. Evaluations that took hours can take milliseconds within a trained domain. Geometry that took an optimisation run or a morning of modelling can appear in seconds. Interactive exploration, in which a designer adjusts a parameter and sees the predicted performance immediately, becomes practical for problems where it was never possible before. These are not small changes, and they will alter how design work is organised. What machine learning does not change is the structure of the problem. The representation still bounds what can be found, and a learned latent space is a representation with all the strengths and limits of the data it came from. The evaluator still has a domain of validity, and learned evaluators have sharper edges to that domain than physics simulations do. The search still exploits whatever the evaluator gets wrong. And the problem statement, whether expressed as loads and constraints or as a text prompt, still determines what is being asked for. If anything, faster and more fluent tools raise the stakes of the problem statement, because they produce more convincing answers to whatever question was posed, more quickly, with less friction to prompt reflection on whether it was the right question. Chapter 8: Where the Judgement Goes The previous chapters followed generative design through structures, aerodynamics, buildings and machine learning, and in each the same pattern appeared. The search algorithms work. They find designs that are excellent according to the problem they were given and the evaluator that scored them. When results disappoint, the cause is almost always that the problem omitted something that mattered, or that the evaluator was wrong in the region where the optimum lay. This chapter draws those threads together and asks what follows for the practice of engineering and architecture: what kinds of judgement the generative workflow demands, how they fail, and how organisations can keep them strong. Four ways to ask the wrong question Problem-definition failures fall into a small number of recurring types, and naming them helps both in avoiding them and in recognising them when an optimised design looks suspicious. The missing requirement. The optimiser removes everything that the stated problem does not require. A load case left out, a vibration mode not constrained, a maintenance access envelope not modelled as a keep-out region, a damage tolerance requirement not encoded: each produces a design that is efficient against an incomplete specification and deficient against the real one. The bracket optimised only for its vertical landing load, mentioned in Chapter 1, is the archetype. Missing requirements are especially dangerous because they are invisible in the output. A design deficient in an unstated respect looks exactly like a good design until someone checks the unstated respect. The proxy objective. The stated objective stands in for what is really wanted, and the two diverge in the region the optimiser explores. Compliance stands in for strength and fatigue life; point drag stands in for performance across a flight envelope; predicted annual energy stands in for real energy use with real occupants. Chapter 3, Chapter 5 and Chapter 6 each showed this in a different form. The proxy is usually chosen for good reasons, tractability above all, and it usually correlates with the true objective across ordinary designs. Optimisation breaks the correlation because it seeks out unusual designs, which is what optimisation is for. The idealised boundary. Every simulation idealises the boundaries of the thing simulated: bolted joints as perfectly rigid, supports as perfectly fixed, materials as perfectly uniform, occupants as following schedules, weather as a typical year. These idealisations are generally harmless for conventional designs with conventional margins. An optimiser may exploit them: concentrating load at a joint modelled as rigid that in reality slips, relying on a support stiffness that the real structure lacks, depending on occupant behaviour that real occupants will not exhibit. The point design. The problem is stated at a single condition, a nominal load, a cruise speed, a typical year, nominal dimensions, when the design will face a distribution of conditions. The optimum at the point is fragile across the distribution. Drela's aerofoils, optimised at one condition and poor at its neighbours, are the classic example, but the pattern appears everywhere manufacturing tolerances, operating conditions or uncertain inputs vary. Each failure has characteristic symptoms in the output and characteristic remedies, which Table 4 summarises. Table 4. Common problem-definition failures in generative design. Failure Typical symptom in the output Remedy Missing requirement Design very efficient in some directions, slender or open in others Systematic review of load cases, environments and lifecycle requirements before running Proxy objective Good on the stated metric, poor in detailed analysis or test Verify with the true criterion; add constraints on what the proxy misses Idealised boundary Load concentrated at joints or supports; reliance on assumed behaviour Model joints and supports realistically; test sensitivity to assumptions Point design Sharp local features; performance falls quickly away from nominal Multipoint or robust formulation across conditions and tolerances The table compresses a lot of practice into a few rows, but it makes one thing clear. None of the remedies is a better algorithm. Each is a more complete or more honest statement of the problem, or a more rigorous verification of the answer. Verification as a first-class activity If problem definition is the front end of the shifted judgement, verification is the back end. In conventional design, verification and design were interleaved: the engineer drew a shape, analysed it, adjusted it, and the analysis grew in fidelity as the design matured. In generative design, the design arrives fully formed from a process that used a particular evaluator, and verification must establish independently that it is sound. Good verification of generative designs has several features. It uses analysis of higher fidelity than the optimiser used: a finer mesh, more realistic boundary conditions, non-linear material behaviour, transient rather than steady analysis, scale-resolving rather than averaged turbulence, multiple weather years and occupant scenarios. It checks criteria the optimiser did not see, such as fatigue, buckling, damage tolerance, manufacturability and inspectability. It tests sensitivity: how much does performance change if a load, a material property or a boundary condition varies within its plausible range? And for anything where failure has serious consequences, it includes physical testing, because every model, however sophisticated, shares assumptions with the model that produced the design, and only reality is independent of them. Verification also has a particular duty with respect to surprises. When a generated design is unexpected, verification should establish whether the surprise reflects a genuine insight into the physics or an artefact of the problem statement or the evaluator. The question to ask of any striking result is: what does this design know that a conventional design does not, and is that knowledge true? Sometimes the answer is a more efficient load path, a better use of solar geometry, a flow feature that reduces drag. Sometimes the answer is that the design has discovered a missing constraint. Treating surprise as a prompt for investigation rather than as a cause for celebration is one of the most useful habits a generative design team can cultivate. The skills the workflow needs Generative design changes what a skilled engineer or architect needs to be able to do, and the change is not the one often predicted. The popular expectation is that automation of form-finding makes design skills less necessary. The evidence of the preceding chapters is the opposite: it makes some skills less necessary and others much more necessary, and the ones that become more necessary are harder to acquire. The skills that become less central are those of producing geometry by hand: drafting, detailed CAD modelling of routine parts, manual iteration on dimensions. These were never the heart of engineering judgement, though they consumed much of engineers' time, and few will miss them. The skills that become more central are those of formulation and evaluation. Formulating a generative problem well requires knowing every requirement a part must satisfy, including the tacit ones that experienced engineers satisfy without thinking: the maintenance technician's need for access, the assembly worker's need to insert a tool, the inspector's need to see, the fatigue behaviour of a printed surface, the occupant's tendency to draw the blinds. It requires knowing the strengths and weaknesses of the evaluator well enough to know where its answers can be trusted. And it requires the physical intuition to look at a generated design and sense whether it is right, which is what tells an engineer when to investigate. There is a real danger here, and it has a well-known name. In 1983 the psychologist Lisanne Bainbridge published a short paper titled "Ironies of Automation", observing that automating the routine parts of a task tends to leave humans responsible for the difficult, unusual parts while depriving them of the routine practice through which they would have developed the skill to handle those parts. Her examples came from process control and aviation, but the irony applies directly to generative design. The intuition that tells an engineer a bracket looks wrong was built partly by drawing and analysing many brackets by hand. Engineers who have only ever specified problems and received answers may lack it. Organisations adopting generative design need to think deliberately about how their engineers will develop physical intuition, through training, through hand analysis of simple cases, through testing and through failure investigation, when the tools no longer require it of them day to day. The workflow also demands people who bridge disciplines. A generative problem in aerospace engages structures, materials, manufacturing, certification and maintenance at once; a generative problem in architecture engages design, building physics, structure, cost and the behaviour of occupants. The quality of the problem statement depends on all of these perspectives entering it, which requires either individuals with broad knowledge or teams that work closely enough to integrate their knowledge into a single specification. In both domains, the most effective generative design teams tend to be small, multidisciplinary and close to testing and manufacturing. The problem statement as a design record One practical consequence of the shift is that the problem statement deserves the same status, scrutiny and documentation as a drawing once had. In a conventional process, the drawing is the authoritative description of the design, and it is reviewed, approved and placed under configuration control. In a generative process, the drawing is an output, and the authoritative description of the design intent is the problem statement: the design space, the load cases, the materials and allowables, the constraints, the objectives, the evaluator and its settings. Organisations that use generative design well treat the problem statement accordingly. They review it before running, with the same multidisciplinary participation as a design review, asking specifically whether any requirement has been omitted and whether the evaluator is appropriate for the region of the design space the optimiser will explore. They archive it with the result, so that anyone examining the design later can see what it was optimised for, which is essential when requirements change, when the part fails in service, or when a regulator asks why the design is as it is. And they version it, because the history of a generative design is mostly a history of changes to its problem statement. Structured review need not be elaborate. A team can make substantial progress by asking a short set of questions before each significant run: 1. What are all the conditions this design must survive, and which of them are in the problem statement? 2. Which of the objectives and constraints are proxies, and for what? 3. Where are the boundaries of the evaluator's validity, and could the optimiser plausibly reach them? 4. Over what range of conditions, tolerances and uncertain inputs must the design perform? 5. How will the result be verified, and by what method independent of the one that produced it? Each question corresponds to one of the failure modes above or to the verification that guards against them. None of them is answered by better software. Understanding why a design is good A generated design arrives without a rationale. A human designer can explain why a bracket has a rib in a particular place: it stiffens the flange against the lateral load. An optimiser cannot explain anything; it simply reports that the design scores well. Yet engineering practice depends on understanding why a design works, because that understanding is what allows a reviewer to judge its soundness, a manufacturer to know which features are critical, and a future engineer to modify it safely when requirements change. Recovering the rationale is therefore part of the work. Several techniques help. Sensitivity analysis asks how the optimised design and its performance respond when each input is varied, which reveals which loads and constraints are actually shaping the result and which are slack. A constraint that is slack contributed nothing to the shape and could have been omitted; a constraint that is active is defining it, and deserves particular scrutiny for whether it was stated correctly. Running the optimisation with each load case removed in turn shows which members exist to carry which loads, reconstructing the load paths a human designer would have drawn deliberately. For multi-objective problems, analysing the designs along the Pareto front, as Obayashi's group did with self-organising maps, shows which design variables govern which trade-offs. The aim is to convert an opaque output into a design the team understands as well as if they had drawn it. This takes time, and it is tempting to skip, particularly under schedule pressure and when the result looks convincing. But a design whose rationale no one understands is fragile in a way that has nothing to do with its physics. When a requirement changes, nobody knows which features can be altered safely. When a part fails in service, nobody knows which assumption was violated. When a supplier proposes a change to ease manufacture, nobody can judge whether it matters. Understanding is what turns a generated shape into an engineered design. Responsibility and standards The professional and legal responsibility for an engineered product does not transfer to an algorithm. An engineer who approves a generatively designed part, or an architect who submits a generatively designed building for approval, is responsible for it exactly as they would be for a hand-drawn design. Professional codes, building regulations and aviation certification rules place obligations on the people and organisations who design and produce, and those obligations are discharged by demonstrating that the design meets its requirements, not by showing that a reputable tool produced it. Standards for the new workflow are still developing. In additive manufacturing, standards bodies including ISO and ASTM International have published a joint series of standards covering terminology, design guidelines, process qualification and testing, and aviation regulators have issued guidance on qualifying printed parts. Standards for generative design as such, for documenting problem statements, validating evaluators or qualifying machine learning surrogates for use in safety-related design, are much less developed. As learned evaluators and generators move into safety-relevant work, the question of how to qualify them, how to demonstrate that a neural surrogate is accurate enough across the region in which it is used, is becoming pressing, and it is likely to be one of the main areas of regulatory and professional activity in the coming years. Judgement relocated, not reduced The argument of this chapter, and of the booklet, is that generative design relocates engineering judgement rather than reducing it. The amount of judgement required is, if anything, greater, because the tools are fast enough to produce many designs and fluent enough to make each look convincing. What has changed is where the judgement is exercised. It has moved upstream, to the formulation of problems, and downstream, to the verification of results, while the middle, the production of form, has been automated. This relocation is not automatically good or bad. Done well, it frees engineers and architects from the most laborious parts of their work and lets them spend their effort on understanding requirements, which is where the most consequential decisions were always made. Done badly, it produces confident, attractive designs optimised for the wrong things, verified by the same assumptions that produced them, approved by people who lack the intuition to see what is missing. The difference lies entirely in whether the people using the tools understand where their judgement now has to be. Conclusion Follow the cost of each part of the generative loop across the chapters of this booklet and a clear trend appears. Producing a candidate shape has become almost free. Topology optimisation carves a bracket in minutes. An evolutionary solver runs thousands of building variants overnight. A trained surrogate scores a new wing in milliseconds, and a generative model or a text-to-CAD system produces editable geometry in seconds. Each decade has removed another factor of cost from the middle of the loop, and machine learning is removing more. The two ends of the loop have not become cheaper. Knowing every requirement a part must meet still takes the accumulated experience of structures, materials, manufacturing, maintenance and certification specialists. Building an evaluator that can be trusted in the region where the optimiser goes still takes validation against tests, and tests cost what they always cost. Establishing the fatigue allowables of a new printed alloy, measuring how real occupants use a real building, flying a wing in a wind tunnel: none of these is accelerated by a faster search algorithm. Some of them have become more expensive, because novel geometry and novel processes demand more testing than familiar ones. When one input to a process becomes abundant, value moves to the inputs that remain scarce. This is the practical conclusion that follows from the preceding chapters, and it runs against much of what is said about AI in design. The competitive advantage in generative design does not lie in the algorithm, which is widely available, often open-source, and rarely the limiting factor. It lies in three things that cannot be generated: complete, honest problem statements; evaluators validated where they are used; and the physical evidence, from material tests, wind tunnels, structural tests and measured building performance, that anchors both. What this means in practice For an engineering organisation deciding how to invest in generative design, this suggests priorities rather different from buying software licences and training people to press the button. The first priority is test data. An organisation that has characterised its materials and processes thoroughly, with allowables that reflect what its qualified processes actually achieve, can let an optimiser work close to those limits with confidence. One that relies on handbook values for a process it has not characterised is optimising against numbers that may not apply. The aerospace organisations that have moved generative parts into service, discussed in Chapter 4, invested heavily in exactly this kind of characterisation, and the investment was the enabling condition rather than a side cost. The second priority is evaluator validation. Every simulation, physics-based or learned, should come with a documented account of the range of designs and conditions over which it has been checked against reality, and generative runs should be constrained or flagged when they leave that range. For learned surrogates this is especially important, because their failures outside the training data are silent. An organisation that treats validation as part of building an evaluator, not an afterthought, can use fast surrogates aggressively. One that does not will eventually build something optimised against a surrogate's mistake. The third priority is the problem statement itself, captured as a reusable asset. The load cases, environments, interface definitions, manufacturing rules and lifecycle requirements for a class of parts represent hard-won knowledge. When they are written down, reviewed and maintained as a library, each new generative run starts from a complete specification, and the tacit knowledge of experienced engineers becomes explicit and transferable. When they are reconstructed from memory for each run, they are incomplete in different ways each time. For architects and building engineers, the same logic applies with a different emphasis. The scarce resource is knowledge of how buildings actually perform once occupied. The performance gap described in Chapter 6 means that the most valuable data a practice can accumulate is measured performance from its own completed buildings, fed back to calibrate the assumptions its simulations use. A practice that does this can trust its generative studies more each year; one that does not will keep optimising against the same optimistic assumptions. Post-occupancy evaluation, long treated as an optional research exercise, becomes the foundation that makes generative performance design meaningful. For individual engineers and architects, the implication is about where to build expertise. Proficiency with generative tools is worth having, but it is the easier skill and the one most likely to be automated further. The durable expertise lies in the requirements and the physics: knowing what a part must survive, why a load path works, where a turbulence model fails, how occupants behave, what a printed surface does to fatigue life. That knowledge is what allows a person to formulate the question well and to recognise a wrong answer that looks right. Bainbridge's irony, discussed in Chapter 8, means that this knowledge may now need to be acquired deliberately, since daily work will no longer build it automatically. What remains unsettled Several questions raised in this booklet remain open, and the answers will shape how far generative methods spread. The first is how learned evaluators and generators will be qualified for safety-relevant work. Physics-based simulation codes have decades of validation behind them and established practices for demonstrating their adequacy. Neural surrogates do not yet have equivalent practices, and their sharp domains of validity make the question harder. Until qualification methods mature, learned tools will likely be confined to exploration and early design in regulated industries, with physics-based verification of final designs. The second is whether data-driven generators can produce designs better than their training data, or only faster versions of it. The evidence so far, discussed in Chapter 7, suggests that generators coupled to physics-based optimisation and evaluation can, while generators trained purely to imitate cannot. The most consequential systems will probably be hybrids, in which learning supplies representation and speed while physics supplies the judgement of quality. The third is how much of problem formulation itself can be assisted by machine learning. Language models can already draft load cases from descriptions, suggest constraints from analogous parts and flag apparently missing requirements. If this assistance works well, it could help with exactly the failures this booklet has emphasised. If it works badly, it could fill gaps in problem statements with plausible defaults that no one checks, which would make the most dangerous failure, the missing requirement, harder to see. Which outcome prevails will depend on whether such systems are built and used to prompt human judgement or to replace it. The question is the design The organic lattice of the Airbus partition, the bent wire of the Space Technology 5 antenna, the long nose of the N700 and the deep western fins of a solar-tuned façade look like the products of machine imagination. They are better understood as answers to carefully posed questions, found by search procedures that are powerful, indifferent and literal. The procedures will find whatever the question permits. They will find it faster every year. And they will exploit every gap between what the question says and what its authors meant. That is why the future of generative design depends less on smarter algorithms than on better questions and more trustworthy evidence. The organisations and individuals who flourish with these tools will be those who understand that the specification is now the design, that the evaluator is now the engineering model of reality, and that both deserve the care, scrutiny and expertise that were once spent on the shape. The machine has taken over the drawing. The responsibility for knowing what should be drawn, and for proving that it works, remains where it always was. Notes Introduction 1. Airbus, "Pioneering bionic 3D printing", Airbus newsroom, March 2016. Source of the 45 per cent (30 kg) mass reduction, the Scalmalloy material and the estimate of up to 465,000 tonnes of CO2 per year. 2. United Nations Environment Programme and Global Alliance for Buildings and Construction, Global Status Report for Buildings and Construction, annual editions, including 2024/2025. Chapter 1 1. A. G. M. Michell, "The limits of economy of material in frame-structures", Philosophical Magazine, series 6, vol. 8, 1904, pp. 589–597. 2. L. A. Schmit, "Structural design by systematic synthesis", Proceedings of the Second ASCE Conference on Electronic Computation, 1960. 3. M. P. Bendsøe and N. Kikuchi, "Generating optimal topologies in structural design using a homogenization method", Computer Methods in Applied Mechanics and Engineering, 71, 1988, pp. 197–224. 4. J. H. Holland, Adaptation in Natural and Artificial Systems, University of Michigan Press, 1975. 5. I. Rechenberg, Evolutionsstrategie: Optimierung technischer Systeme nach Prinzipien der biologischen Evolution, Frommann-Holzboog, 1973. 6. S. Krish, "A practical generative design method", Computer-Aided Design, 43(1), 2011, pp. 88–100. Chapter 2 1. G. S. Hornby, J. D. Lohn and D. S. Linden, "Computer-automated evolution of an X-band antenna for NASA's Space Technology 5 mission", Evolutionary Computation, 19(1), 2011, pp. 1–23. 2. K. Deb, "An efficient constraint handling method for genetic algorithms", Computer Methods in Applied Mechanics and Engineering, 186, 2000, pp. 311–338. 3. N. Hansen and A. Ostermeier, "Completely derandomized self-adaptation in evolution strategies", Evolutionary Computation, 9(2), 2001, pp. 159–195. 4. K. Deb, A. Pratap, S. Agarwal and T. Meyarivan, "A fast and elitist multiobjective genetic algorithm: NSGA-II", IEEE Transactions on Evolutionary Computation, 6(2), 2002, pp. 182–197. 5. S. Obayashi and D. Sasaki, "Visualization and data mining of Pareto solutions using self-organizing map", in Evolutionary Multi-Criterion Optimization, Springer, 2003. 6. D. H. Wolpert and W. G. Macready, "No free lunch theorems for optimization", IEEE Transactions on Evolutionary Computation, 1(1), 1997, pp. 67–82. Chapter 3 1. M. P. Bendsøe, "Optimal shape design as a material distribution problem", Structural Optimization, 1, 1989, pp. 193–202. 2. K. Svanberg, "The method of moving asymptotes: a new method for structural optimization", International Journal for Numerical Methods in Engineering, 24, 1987, pp. 359–373. 3. O. Sigmund, "A 99 line topology optimization code written in Matlab", Structural and Multidisciplinary Optimization, 21, 2001, pp. 120–127. 4. E. Andreassen, A. Clausen, M. Schevenels, B. S. Lazarov and O. Sigmund, "Efficient topology optimization in MATLAB using 88 lines of code", Structural and Multidisciplinary Optimization, 43, 2011, pp. 1–16. 5. O. Sigmund, "On the usefulness of non-gradient approaches in topology optimization", Structural and Multidisciplinary Optimization, 43, 2011, pp. 589–596. 6. N. Aage, E. Andreassen, B. S. Lazarov and O. Sigmund, "Giga-voxel computational morphogenesis for structural design", Nature, 550, 2017, pp. 84–86. 7. Y. M. Xie and G. P. Steven, "A simple evolutionary procedure for structural optimization", Computers and Structures, 49(5), 1993, pp. 885–896. 8. M. Y. Wang, X. Wang and D. Guo, "A level set method for structural topology optimization", Computer Methods in Applied Mechanics and Engineering, 192, 2003, pp. 227–246; G. Allaire, F. Jouve and A.-M. Toader, "Structural optimization using sensitivity analysis and a level-set method", Journal of Computational Physics, 194, 2004, pp. 363–393. 9. A. T. Gaynor and J. K. Guest, "Topology optimization considering overhang constraints: eliminating sacrificial support material in additive manufacturing through design", Structural and Multidisciplinary Optimization, 54, 2016, pp. 1157–1172. Chapter 4 1. Airbus newsroom, March 2016, as in the Introduction. 2. General Motors and Autodesk, announcement of collaboration on generative design and additive manufacturing, May 2018, reporting the eight-into-one seat bracket. 3. NASA, reports and presentations by Ryan McClelland on "evolved structures", NASA Goddard Space Flight Center, 2023 onwards, including material on the NASA Technical Reports Server; and press coverage, for example The Register, 13 February 2023. 4. GE Aviation public statements on the LEAP fuel nozzle, the GE90 sensor housing approved by the FAA in 2015, and the Catalyst turboprop. Chapter 5 1. R. M. Hicks and P. A. Henne, "Wing design by numerical optimization", Journal of Aircraft, 15(7), 1978, pp. 407–412. 2. B. M. Kulfan, "Universal parametric geometry representation method", Journal of Aircraft, 45(1), 2008, pp. 142–158. 3. T. W. Sederberg and S. R. Parry, "Free-form deformation of solid geometric models", ACM SIGGRAPH Computer Graphics, 20(4), 1986, pp. 151–160. 4. A. Jameson, "Aerodynamic design via control theory", Journal of Scientific Computing, 3, 1988, pp. 233–260. 5. Z. Lyu, G. K. W. Kenway and J. R. R. A. Martins, "Aerodynamic shape optimization investigations of the Common Research Model wing benchmark", AIAA Journal, 53(4), 2015, pp. 968–985. 6. D. R. Jones, M. Schonlau and W. J. Welch, "Efficient global optimization of expensive black-box functions", Journal of Global Optimization, 13, 1998, pp. 455–492. 7. M. C. Kennedy and A. O'Hagan, "Predicting the output from a complex computer code when fast approximations are available", Biometrika, 87(1), 2000, pp. 1–13. 8. J. R. R. A. Martins and A. B. Lambe, "Multidisciplinary design optimization: a survey of architectures", AIAA Journal, 51(9), 2013, pp. 2049–2075. 9. M. Drela, "Pros and cons of airfoil optimization", in Frontiers of Computational Fluid Dynamics 1998, World Scientific, 1998. Chapter 6 1. D. B. Crawley et al., "EnergyPlus: creating a new-generation building energy simulation program", Energy and Buildings, 33(4), 2001, pp. 319–331. 2. M. S. Roudsari and M. Pak, "Ladybug: a parametric environmental plugin for Grasshopper to help designers create an environmentally-conscious design", Proceedings of Building Simulation 2013, IBPSA. 3. A.-T. Nguyen, S. Reiter and P. Rigo, "A review on simulation-based optimization methods applied to building performance analysis", Applied Energy, 113, 2014, pp. 1043–1058. 4. D. Nagy et al., "Project Discover: an application of generative design for architectural space planning", Proceedings of SimAUD 2017. 5. P. de Wilde, "The gap between predicted and measured energy performance of buildings: a framework for investigation", Automation in Construction, 41, 2014, pp. 40–49. Chapter 7 1. T. Pfaff, M. Fortunato, A. Sanchez-Gonzalez and P. W. Battaglia, "Learning mesh-based simulation with graph networks", International Conference on Learning Representations, 2021. 2. Z. Li et al., "Fourier neural operator for parametric partial differential equations", International Conference on Learning Representations, 2021. 3. M. Raissi, P. Perdikaris and G. E. Karniadakis, "Physics-informed neural networks", Journal of Computational Physics, 378, 2019, pp. 686–707. 4. S. Oh, Y. Jung, S. Kim, I. Lee and N. Kang, "Deep generative design: integration of topology optimization and generative models", Journal of Mechanical Design, 141(11), 2019. 5. F. Mazé and F. Ahmed, "Diffusion models beat GANs on topology optimization", Proceedings of the AAAI Conference on Artificial Intelligence, 2023. 6. L. Regenwetter, A. H. Nobari and F. Ahmed, "Deep generative models in engineering design: a review", Journal of Mechanical Design, 144(7), 2022. 7. J.-B. Mouret and J. Clune, "Illuminating search spaces by mapping elites", arXiv:1504.04909, 2015. 8. S. Koch et al., "ABC: a big CAD model dataset for geometric deep learning", CVPR, 2019; K. D. D. Willis et al., "Fusion 360 Gallery: a dataset and environment for programmatic CAD construction from human design sequences", ACM Transactions on Graphics, 40(4), 2021. 9. R. Wu, C. Xiao and C. Zheng, "DeepCAD: a deep generative network for computer-aided design models", ICCV, 2021. 10. Autodesk, announcements of neural CAD foundation models at Autodesk University, September 2025. Chapter 8 1. L. Bainbridge, "Ironies of automation", Automatica, 19(6), 1983, pp. 775–779. 2. ISO/ASTM 52900 series of additive manufacturing standards, including ISO/ASTM 52910 on design guidelines. Further Reading Joaquim R. R. A. Martins and Andrew Ning, Engineering Design Optimization (Cambridge University Press, 2021).** The best single modern textbook on the subject, covering gradient-based and gradient-free methods, surrogates, multi-objective and multidisciplinary optimisation with engineering examples throughout. A free version has been made available by the authors. Martin P. Bendsøe and Ole Sigmund, Topology Optimization: Theory, Methods and Applications (Springer, 2003).** The standard reference on topology optimisation by two of its founders. Mathematical, but the opening chapters are accessible to any engineer. Ole Sigmund, "A 99 line topology optimization code written in Matlab" (2001), and Erik Andreassen and colleagues, "Efficient topology optimization in MATLAB using 88 lines of code" (2011). Short, readable papers that let anyone run topology optimisation and see its behaviour first-hand, which is the quickest way to understand it. Alexander Forrester, András Sóbester and Andy Keane, Engineering Design via Surrogate Modelling: A Practical Guide (Wiley, 2008).** A clear, practical introduction to kriging, expected improvement and multi-fidelity methods for designers with expensive simulations. Kalyanmoy Deb, Multi-Objective Optimization Using Evolutionary Algorithms (Wiley, 2001).** A comprehensive account of evolutionary multi-objective optimisation by the author of NSGA-II. Mark Drela, "Pros and Cons of Airfoil Optimization" (1998). A short, wise paper on how optimisers exploit narrow problem statements; essential reading for anyone setting up an aerodynamic optimisation, and instructive well beyond aerodynamics. Lyle Regenwetter, Amin Heyrani Nobari and Faez Ahmed, "Deep Generative Models in Engineering Design: A Review" (Journal of Mechanical Design, 2022). A thorough survey of machine learning generators in engineering, with a valuable critique of how they are evaluated. Pieter de Wilde, "The gap between predicted and measured energy performance of buildings" (Automation in Construction, 2014). The clearest review of why building simulation and building reality diverge, and what that means for anyone optimising against simulation. Lisanne Bainbridge, "Ironies of Automation" (Automatica, 1983). Four pages written about process control that say more about the human side of generative design than most of the literature on generative design itself. Hashtags: #GenerativeDesignInEngineering #GenerativeDesign #AIDrivenDesign #ArtificialIntelligence #AIInEngineering #AIDrivenCAD #ComputerAidedDesign #CAD #EngineeringDesign #ComputationalDesign #AlgorithmicDesign #ParametricDesign #DesignOptimization #EngineeringOptimization #TopologyOptimization #StructuralOptimization #ShapeOptimization #MultiObjectiveOptimization #EvolutionaryAlgorithms #GeneticAlgorithms #EvolutionStrategies #CMAES #NSGAII #ParetoOptimization #ParetoFront #GradientBasedOptimization #BayesianOptimization #SurrogateModeling #MachineLearning #DeepLearning #GenerativeAI #AIGeneratedGeometry #EditableCAD #FiniteElementAnalysis #FEA #ComputationalFluidDynamics #CFD #AerodynamicOptimization #AerodynamicDesign #StructuralLightweighting #LightweightStructures #AerospaceEngineering #AircraftDesign #SpacecraftEngineering #AutomotiveEngineering #AdditiveManufacturing #ThreeDPrinting #DesignForAdditiveManufacturing #LatticeStructures #BiomimeticDesign #BioInspiredEngineering #MaterialOptimization #PartConsolidation #ManufacturingConstraints #EngineeringSimulation #SimulationDrivenDesign #PhysicsBasedOptimization #DesignSpaceExploration #ConstraintBasedDesign #PerformanceBasedDesign #BuildingPerformanceSimulation #GenerativeArchitecture #ComputationalArchitecture #ArchitecturalOptimization #BuildingEnergyOptimization #EnergyEfficientBuildings #SustainableArchitecture #DaylightOptimization #ThermalComfort #Grasshopper3D #Rhinoceros3D #AutodeskGenerativeDesign #DigitalEngineering #EngineeringInnovation #DesignVerification #EngineeringValidation #FutureOfEngineering

Download the Book (PDF): Introduction Most machine learning failures in production do not look like failures. The service stays up. The latency graphs stay flat. The model keeps returning predictions with the same confidence it had on launch day. What has changed is somewhere upstream: a field that used to arrive in kilograms now arrives in grams, a join that used to match ninety-eight percent of rows now matches sixty, a mobile client release has started sending a default value where it once sent nothing, a timestamp column quietly switched from local time to UTC. The model, which has no way of knowing any of this, does exactly what it was trained to do with inputs it was never trained on. Revenue drifts down, or fraud losses drift up, or a recommendation feed gets subtly worse, and weeks pass before anyone traces the cause back to the data. This booklet is about preventing that kind of failure. Its argument is simple to state and demanding to practise: the quality of a machine learning system is bounded by the pipeline that feeds it, and the most damaging pipeline failures are silent ones. A model cannot be better than the data it learns from, and it cannot behave in production the way it behaved in evaluation unless the data it sees in production is computed the same way, from the same definitions, with the same respect for time. Everything else in this book follows from taking that seriously. Why the data work is the hard part There is a well-known paper from Google engineers, D. Sculley and colleagues, presented at NeurIPS in 2015 under the title "Hidden Technical Debt in Machine Learning Systems." Its most quoted observation is that in a mature production ML system, the code that actually implements the learning algorithm is a small fraction of the whole. Around it sits a much larger body of configuration, data collection, feature extraction, data verification, serving infrastructure and monitoring. The paper's point was not that models are unimportant but that the surrounding machinery is where the complexity, and therefore the risk, accumulates. It named failure patterns that every practitioner now recognises: entanglement, where changing one input changes everything; undeclared consumers, where a model's outputs quietly become another system's inputs; and pipeline jungles, where data preparation grows by accretion until nobody can say exactly what it does. Six years later, a team led by Nithya Sambasivan at Google published a study at the CHI conference with the pointed title "Everyone wants to do the model work, not the data work." Drawing on interviews with practitioners building AI systems in high-stakes domains, the authors described what they called data cascades: compounding events, caused by data issues, that produce negative downstream effects, often discovered late and often invisible until they had already done damage. The study found such cascades to be widespread among the practitioners interviewed. The reason was cultural as much as technical. Data work was undervalued, under-rewarded and treated as a preliminary chore before the interesting part began. These two papers bracket the problem. The first says that the data machinery is where ML systems are complex. The second says that organisations systematically underinvest in exactly that machinery. The result is a field in which teams spend months tuning architectures and hours, if that, deciding how a timestamp should be handled in a join. What this booklet covers The booklet follows data from the moment it is produced to the moment a model consumes it, and asks at each stage what can go wrong silently and how to stop it. Chapter 1 sets out why ML pipelines fail differently from ordinary software, and why the conventional tools of software reliability, such as tests, type systems and uptime monitoring, catch so little of what goes wrong. Chapter 2 deals with ingestion: how data enters the platform, through batch extracts, change data capture from operational databases, or event streams, and what each path guarantees and fails to guarantee. Chapter 3 is about time, which is the single most common source of subtle error in ML data, from label leakage to point-in-time joins to backfills that rewrite history. Chapter 4 turns to feature stores: what problem they were invented to solve, what they actually consist of, and when a team does or does not need one. Chapter 5 explains Apache Kafka in enough depth to design with it rather than around it, with particular attention to the properties that matter for telemetry feeding models: partitioning, ordering, retention and delivery guarantees. Chapter 6 covers stream processing, where raw events become features in real time, and the hard questions of windows, watermarks, late data and state. Chapter 7 is the centre of the book's argument: data quality, checked before data reaches the network. It covers schema enforcement, data contracts, statistical validation, label quality and the detection of drift, and argues for treating each boundary in the pipeline as a place where data must prove itself before it moves on. Chapter 8 deals with the operation of all this over time: lineage, versioning, reproducibility, ownership and the newer pipelines that feed large language models with documents and embeddings rather than rows and columns. Who this is for The reader I have in mind is technically literate but not necessarily a data engineer. It might be a machine learning engineer who has trained models on clean, prepared datasets and is now responsible for one in production. It might be a software engineer moving into a data platform team, a technical manager trying to understand why a model that worked in the notebook does not work in the product, or a data scientist who suspects that their most persistent problems are not modelling problems at all. The book assumes familiarity with basic ideas such as tables, joins, APIs and the general shape of supervised learning. It does not assume familiarity with any particular tool. Where tools are named, and many are, it is because they illustrate a design choice that outlives them. Kafka, Flink, Feast, Delta Lake, Iceberg and the various validation libraries will change; the questions they answer about ordering, state, consistency and correctness will not. A word on what is left out A short book has to choose. This one does not cover model training, hyperparameter tuning, distributed training infrastructure or model serving architectures except where they touch the data. It does not survey every vendor, and it does not attempt a comparison of cloud data warehouses. It says relatively little about data governance in the legal and regulatory sense, although Chapter 8 touches on lineage and retention, which are the technical substrate of governance. It treats unstructured data pipelines for language models as a variation on the same principles rather than a separate discipline, because in practice that is what they are. What remains is a single line of argument followed from source to model. Data is produced by systems that were not designed with machine learning in mind. It must be moved without losing or duplicating it, aligned in time without leaking the future, transformed identically for training and for serving, and checked at every boundary so that when something changes, and something always changes, the pipeline stops loudly instead of failing quietly. Doing that well is not glamorous. It is, more often than any other single factor, what separates machine learning systems that work from those that merely run. Chapter 1: Why Machine Learning Pipelines Fail Silently Ordinary software fails in ways that announce themselves. A null pointer throws an exception. A misconfigured endpoint returns a 500. A database migration that drops a column breaks every query that touches it, and the error logs fill within seconds. Decades of engineering practice, from type systems to unit tests to health checks, are built around the assumption that incorrect behaviour will manifest as visible error. That assumption is mostly sound for conventional programs, because their behaviour is specified by code, and code that is wrong usually fails when it runs. A machine learning system is different in a way that matters enormously for reliability. Its behaviour is specified jointly by code and by data, and the data half of the specification is never written down. The model learned a function from a particular distribution of inputs. Nothing in the code says what that distribution was. When the inputs change, the model does not fail; it extrapolates. It produces an output of exactly the right type and shape, within exactly the expected range, at exactly the expected latency. Every conventional check passes. The system is wrong, and nothing says so. The model as an unwritten contract Consider a credit risk model trained on applicant data where a field called annual_income was populated from a form that asked for gross annual income in local currency. Some months after deployment, a product team redesigns the application form. The new version asks for monthly income, because user research showed applicants found that easier to answer, and a backend developer, reasonably enough, stores it in the same column. Nobody tells the ML team, because nobody thinks of the ML team as a consumer of that column. It is just a field in the applications table. From the moment the new form ships, the model sees incomes roughly one-twelfth of what it was trained on. Applicants look dramatically poorer. Depending on how the model uses income, approval rates may fall, or risk scores may rise across the board, or the effect may be dampened by other features and appear only as a slight degradation in a few segments. In none of these cases does anything crash. The model's output is a valid probability. The service is healthy. The first signal is likely to be a business metric, such as approval rates or loss rates, moving in a way that someone eventually finds suspicious. This is the defining characteristic of ML data failures: the model encodes an implicit contract with its inputs, and that contract has no enforcement mechanism unless someone deliberately builds one. Every assumption the model absorbed during training, about units, ranges, distributions, null rates, category vocabularies, the relationships between fields and the timing of when values become known, is a clause in a contract that the upstream systems never signed and do not know exists. A taxonomy of silent failure It helps to name the main ways the contract gets broken, because each calls for a different defence. The rest of this booklet is organised, in effect, around these failure classes. Schema changes are the most tractable. A column is renamed, dropped, retyped or added. A nested JSON field moves. An enum gains a new value. These are visible in principle, because the structure of the data changed, but they slip through when pipelines are permissive: when a missing column is filled with nulls, when an unknown category is mapped to a default, when a string that used to be numeric is coerced and the failures become NaN. Permissive parsing is often adopted deliberately, to keep pipelines running, and it converts a loud failure into a silent one. Semantic changes are harder. The schema is identical but the meaning has shifted, as in the income example. A status code is reused for a new purpose. A field that used to be populated by users is now populated by a default. A timestamp moves from local time to UTC, or from event time to processing time. A product catalogue reorganisation changes which items fall into which category. Nothing structural has changed, so schema validation passes. Only checks on the values themselves, and on their distributions, can catch these. Distribution shift is change in the world rather than in the pipeline. Customer behaviour changes with seasons, economic conditions, competitor actions or pandemics. A fraud model trained before a new attack pattern emerges does not know about it. This is not a data engineering bug, but a data platform must detect it, because the model's owners need to know when the inputs no longer resemble the training set, and the platform is the only place where both are visible. Training-serving skew is a mismatch between how features are computed for training and how they are computed at prediction time. It is the most insidious failure class because it can be present from the first day of deployment, so there is no "before" to compare against. A feature computed in SQL in the warehouse for training and reimplemented in Java in the serving path will almost always differ in some edge case, whether null handling, rounding, time zone treatment or the precise definition of a window. Google's "Rules of Machine Learning," a widely circulated guide written by Martin Zinkevich, gives this problem extended attention and recommends, among other things, logging the features actually used at serving time so they can be reused for training. Chapter 4 returns to it in detail. Leakage is the use, during training, of information that would not be available at prediction time. The classic case is a feature computed over a window that extends past the moment the prediction would have been made, so the model learns from a peek at the future. Leakage produces models that look superb in offline evaluation and disappoint in production. Chapter 3 is devoted to it. Pipeline faults are the familiar engineering failures, such as jobs that partially succeed, retries that duplicate records, late-arriving partitions that are skipped, backfills that overwrite good data with bad, and joins whose keys have drifted out of alignment. These are ordinary bugs, but in an ML context they are rarely caught by the downstream consumer, because a model will happily train on a dataset that is missing a day, or contains every Tuesday twice. Why the usual safeguards miss these Software engineering has developed an excellent set of reliability tools. It is worth being precise about why each of them, used alone, misses most of the failures above. Unit tests verify that code does what its author intended on inputs its author imagined. A transformation that converts currency, for instance, can be tested on a handful of fixtures. But the failure in the income example is not that the code is wrong. The code is correct for the data it was written against; the data changed. Tests on fixed fixtures cannot detect a change in the live input distribution. Type systems and schemas verify structure. They will catch a string where an integer was expected. They will not catch an integer that is twelve times too small. Uptime and latency monitoring verify that the service responds. A model serving garbage predictions with perfect availability is green on every dashboard. Integration tests in a staging environment verify that components work together. But staging data is usually a sample or a synthetic stand-in, and the distributional properties that models depend on are exactly what sampling and synthesis fail to preserve. Model evaluation on a held-out test set verifies that the model generalises within the distribution it was trained on. If the test set was constructed by the same pipeline as the training set, it shares every bias, every leak and every skew that pipeline introduced. A leaking feature inflates test performance just as much as training performance. None of this means these tools are useless. A mature ML platform uses all of them. The point is that they were designed for a world where behaviour is specified by code, and they need supplementing by tools designed for a world where behaviour is specified by data. Those tools are the subject of this booklet: explicit schemas and contracts enforced at boundaries, point-in-time correctness in feature computation, shared feature definitions for training and serving, statistical validation of every batch, and monitoring of input distributions alongside output metrics. The economics of late detection There is a reason to care about where in the pipeline a problem is caught, beyond tidiness. The cost of a data error grows with the distance it travels before detection. A malformed record rejected at ingestion costs almost nothing: it lands in a dead-letter queue, someone looks at it, the producer is fixed. The same record accepted at ingestion, transformed, joined, aggregated into a feature, written to a feature store, used to train a model and served in production has been copied into a dozen derived datasets. Fixing it means identifying every downstream artefact that consumed it, recomputing them, possibly retraining and redeploying the model, and then working out what the business impact of the bad predictions was in the meantime. If the error was a systematic one, such as a units change affecting every record from a certain date, the remediation can take weeks. The Sambasivan study described exactly this pattern. Practitioners reported data problems that originated early, in collection or labelling, and surfaced late, after deployment, often only through their effects on end users. The cascades were costly precisely because of the distance between cause and detection. Several practitioners described having to discard work, re-collect data or rebuild systems. This argues for a particular architecture of defence: checks concentrated at boundaries, as early as possible, with a bias toward stopping the pipeline rather than letting questionable data through. It is the opposite of the instinct that many data teams have, which is to keep pipelines running at all costs because downstream consumers complain when data is late. Late data is visible and recoverable. Wrong data that arrives on time is neither. Feedback loops: when the model writes its own training data One class of silent failure deserves separate treatment because it is created by the model itself. Once a model is deployed, its decisions start to shape the data that will later be used to retrain it. The pipeline faithfully records what happened, but what happened was partly caused by the previous model. A recommendation system is the clearest example. It shows users items it predicts they will click. Users click some of them. Those clicks become training labels for the next version. Items the model never showed have no clicks, not because users would not have liked them but because users never saw them. Over successive retrainings, the model's view of the world narrows toward what it already believed. Nothing in the data looks wrong. Every logged impression and click is accurate. The bias lives in what was never logged. Credit and fraud models suffer a related problem, sometimes called selective labels. A lending model approves some applicants and rejects others. Outcomes, repayment or default, are observed only for the approved applicants. The next model is trained on a population filtered by the previous one, and has no information at all about whether rejected applicants would have repaid. A fraud model that blocks suspicious transactions likewise never learns whether the blocked ones were really fraud, because blocked transactions generate no chargebacks. These loops are data engineering problems as much as modelling problems, because the remedies live in the pipeline. The first remedy is to log not just outcomes but the decision context: which items were shown, in what positions, with what predicted scores, and which model version made the decision. Without that record, later analysis cannot separate the effect of the model from the behaviour of users. The second remedy is deliberate exploration: a small fraction of traffic where the system shows randomised recommendations, or approves a sample of borderline applicants, so that unbiased outcome data keeps flowing. The data from these exploration slices must be flagged in the pipeline and treated specially in training, often with weights derived from the logged probability that each item was shown. The third remedy is simply awareness: any training set built from data the model influenced should be documented as such, so that nobody mistakes it for a neutral sample of the world. Feedback loops are slow. They can take months of retraining cycles to produce visible degradation, which makes them perhaps the most silent failure of all. The only defence that works is to design the logging for them from the start, because the information needed to correct them cannot be reconstructed after the fact. Ownership is part of the architecture The final reason ML pipelines fail silently is organisational. The team that produces data, usually an application team building a product, and the team that consumes it for machine learning are typically different teams with different priorities, different on-call rotations and different definitions of success. The application team is measured on shipping features. Its database is an implementation detail of its service. When it renames a column, the change is reviewed by its own engineers against its own tests, all of which pass. The ML team, meanwhile, is reading that database, often through a replication pipeline or a nightly extract, and treating it as a stable interface. It is not. It was never declared as one, and the producing team has no idea it is being used this way. This is the undeclared consumer problem from the Sculley paper, inverted: the ML system is the undeclared consumer of someone else's internals. Every durable solution to silent data failure involves making this relationship explicit. Sometimes that takes the form of a data contract, a declared schema and set of semantic guarantees that the producer commits to and that is enforced in their CI pipeline. Sometimes it takes the form of an event stream that the producer publishes deliberately, as a product, rather than a database that consumers scrape. Sometimes it is simply a list of downstream consumers that the producer must notify before changing a table. The technical mechanisms vary; the principle does not. Data that feeds a model must have an owner who knows it feeds a model. The rest of this booklet builds up, layer by layer, the technical machinery that makes this possible. It begins where data enters the platform, because that is the first boundary and the cheapest place to catch a problem. Chapter 2: Ingestion: Getting Data In Without Losing the Truth Every machine learning pipeline begins by taking data from somewhere it was not designed to be taken from. Operational databases exist to serve applications. Logs exist for debugging. Third-party APIs exist to serve their vendor's customers, not your feature computation. Ingestion is the act of pulling data out of these systems and landing it somewhere it can be analysed, and the design choices made here determine, more than any later choice, whether the pipeline can be trusted. The goal of ingestion is easy to state: capture what happened in the source system, completely and accurately, with enough information about when it happened to reconstruct the past. Each part of that sentence is harder than it looks. "Completely" means no records lost, including records deleted at the source. "Accurately" means no records duplicated or corrupted. "When it happened" means preserving event time, not just the time the pipeline noticed. "Reconstruct the past" means being able to answer, months later, the question: what did this table look like at three o'clock on the fourteenth of March? That last requirement is the one ML pipelines need most and conventional analytics pipelines most often neglect. A dashboard showing current customer counts only needs the current state. A model trained to predict churn needs to know what each customer looked like at the moment a prediction would have been made, which might be any moment in the last two years. If ingestion only captures current state, that history is gone, and no amount of downstream cleverness can recover it. Three ways in There are three broad patterns for ingesting data, and most real platforms use all of them. They differ in latency, in how much history they preserve, in the load they place on the source and in the failure modes they introduce. Table 1 summarises the differences, which the sections below explain. Table 1. The three main ingestion patterns compared. Pattern Typical latency History preserved Load on source Main risk Batch extract Hours to a day Snapshots only High during extract Missed deletes and intra-day changes Change data capture Seconds to minutes Every committed change Low (reads log) Schema changes break the stream Application events Sub-second Every emitted event None on database Producer bugs and inconsistent schemas Batch extracts The oldest pattern, and still the most common, is the periodic extract. Once a night, or once an hour, a job runs a query against the source database, often SELECT * FROM orders WHERE updated_at > :last_run, and writes the result to object storage or a warehouse. It is simple, it uses tools everyone understands and it requires nothing from the source system except read access. Its weaknesses are structural. A query against current state sees only the latest version of each row; if a row was updated three times between extracts, two of those states are lost. Deleted rows simply vanish, since a query cannot return a row that no longer exists, so the warehouse keeps a stale copy forever unless a separate reconciliation catches it. Incremental extraction by updated_at depends on every code path that modifies the row also updating that column, which is a discipline application teams frequently break with bulk updates, manual fixes and migrations. Clock differences between application servers can cause rows to be updated with timestamps slightly in the past, so that they fall behind the high-water mark and are skipped. Full snapshot extracts avoid the incremental problems by copying the whole table each time, at the cost of load and storage. Kept as dated snapshots, they do support a coarse form of time travel: the state of the table as of each extract. For slowly changing reference data this can be adequate. For anything where intra-day changes matter to the model, it is not. Change data capture Change data capture, usually called CDC, reads the database's own transaction log, the write-ahead log in PostgreSQL or the binlog in MySQL, and emits a record for every committed insert, update and delete. Because it reads the log rather than querying tables, it sees every change, in commit order, including deletes, with negligible load on the source. Debezium, an open-source project originally sponsored by Red Hat, is the most widely used tool for this and typically publishes change events to Kafka, one topic per table. Cloud providers and commercial vendors offer managed equivalents. A CDC event usually contains the row's state before the change, its state after, the operation type and metadata including the source transaction's commit time and log position. That is a complete history. Replaying the change stream from the beginning reconstructs the table at any point in time, which is precisely what point-in-time feature computation needs. CDC has its own sharp edges. It requires privileged access to the database log, which database administrators are rightly cautious about granting. Initial setup requires a consistent snapshot of the existing table followed by a seamless switch to streaming changes, which tools handle but which can be operationally delicate on very large tables. Log retention on the source must be long enough that a paused connector can resume without the log having been truncated; if it falls too far behind, a fresh snapshot is needed. And schema changes in the source table flow straight into the change stream. A column added by an application migration appears in the next event; a column dropped disappears. Whether downstream consumers handle that gracefully depends on schema management, discussed below. There is a subtler issue. CDC captures the database's physical changes, not the business events behind them. An order that moves from "pending" to "paid" to "shipped" produces three update events, each a full row image. To recover the business meaning, which is that a payment happened at a certain time, downstream logic has to diff the before and after images and infer it. When a single business action touches several tables in one transaction, the consumer must reassemble the transaction from separate topics. This is doable, but it means CDC consumers are coupled to the source's internal schema, with all the fragility Chapter 1 described. Application events The third pattern is for applications to publish events deliberately: OrderPlaced, PaymentCaptured, ItemViewed, SessionStarted. Each event is a statement that something happened, with the fields relevant to it, emitted at the moment it happened. Clickstream and telemetry data almost always arrives this way, because there is no database table behind a page view or a sensor reading. Events designed as a product have a large advantage over CDC: they express business meaning directly and they decouple consumers from the producer's storage schema. The application can refactor its database freely as long as it keeps publishing the same events. This is the foundation of the data contract idea that Chapter 7 develops. Their disadvantage is that they are only as reliable as the code that emits them. If an application writes to its database and then publishes an event as a separate step, a crash between the two leaves the database and the event stream inconsistent. The standard solution is the transactional outbox pattern: the application writes the event to an outbox table in the same database transaction as the business change, and a separate process, frequently a CDC connector, relays outbox rows to the event stream. This guarantees that an event is published if and only if the corresponding change committed. It is one of the most useful patterns in data engineering and one of the least widely adopted. Client-side events, such as those from mobile apps and browsers, are less reliable still. Devices go offline and send batches of events hours later. Clocks on client devices are wrong, sometimes by years. Ad blockers drop analytics calls. Old app versions remain in the wild for months, emitting events in obsolete formats. Any pipeline consuming client telemetry must assume that events will be late, duplicated, out of order and occasionally absurd, and must be designed accordingly. External and third-party data A fourth source deserves mention because it behaves differently from the other three: data bought from or supplied by outside parties. Credit bureau records, weather feeds, geolocation enrichment, market prices, demographic tables and partner exports all find their way into ML features, often as some of the most predictive inputs a model has. External data arrives on someone else's schedule, under someone else's schema and with someone else's definition of correctness. Vendors revise historical values without notice, change file layouts between deliveries, re-baseline indices and occasionally deliver a file that is simply empty. Because the producing team is outside the organisation, the conversations that a data contract depends on are slower and more formal, conducted through account managers and service agreements rather than a message to a colleague. Three habits help. Store every delivery as received, with its arrival time and a checksum, so that revised history is detectable: if the vendor's March figures differ between the April and May deliveries, the pipeline should notice rather than silently adopt the new values. Validate each delivery against the previous one before accepting it, with volume, schema and distribution checks of the kind Chapter 7 describes. And for point-in-time correctness, record which version of the external data was available at each moment, not just the latest version. A model trained on revised economic indicators, using values that were published months after the period they describe, has leaked the future in a way that is easy to miss because the leak is in the vendor's data, not in the team's own code. Licensing deserves a word too. External data often comes with restrictions on how long it may be retained, what it may be used for and whether derived models may be used in particular ways. Those terms are part of the data's definition as surely as its schema, and the ingestion layer is the natural place to attach them as metadata so that downstream users can see them. Landing data: raw first, always Whatever the ingestion pattern, one principle holds: land the raw data first, unchanged, before doing anything else to it. This is sometimes called the bronze layer, in the "medallion" terminology popularised by Databricks, where bronze holds raw ingested data, silver holds cleaned and conformed data, and gold holds business-level aggregates and features. The names are marketing, but the discipline is sound. Keeping an immutable raw copy matters for ML in particular because transformations change. A feature definition will be revised; a bug in a parsing step will be discovered; a new model will want a field that the original cleaning step discarded. If the raw data is retained, all of these are recoverable by reprocessing. If only the cleaned output was kept, the information destroyed by the old transformation is gone. Storage is cheap relative to the cost of being unable to rebuild a training set. The raw layer should record, alongside each record, the metadata of its arrival: when it was ingested, from which source, by which connector version, from which file or log offset. This ingestion metadata is distinct from the event's own timestamps and serves a different purpose. It lets an engineer answer questions such as which records arrived in the batch that caused yesterday's anomaly, or which records were processed by the connector version that had the bug. Table formats and why they matter here Raw and processed data in modern platforms increasingly lives in object storage, such as Amazon S3, Google Cloud Storage or Azure Blob Storage, as Parquet files managed by an open table format: Apache Iceberg, Delta Lake or Apache Hudi. These formats add, on top of plain files, a transaction log that tracks which files make up the table at each version. For ML pipelines three properties of these formats are especially valuable. First, atomic commits: a write either fully succeeds or is not visible, so a downstream job never reads a half-written partition. Plain directories of files offer no such guarantee, and partially written outputs are a classic source of training sets that are quietly missing data. Second, time travel: because each commit is a version, a table can be queried as of a past version or timestamp. This makes it possible to reproduce exactly the data a model was trained on, as Chapter 8 discusses, and it makes backfills safer because the previous state can be restored. Third, schema evolution with enforcement: the table's schema is recorded in its metadata, writes that violate it are rejected, and permitted evolutions such as adding a nullable column are tracked. Time travel in table formats is not a substitute for capturing history at ingestion. It retains past versions of the table only for as long as old files are kept, which is often days or weeks, after which compaction and cleanup remove them. It records the pipeline's history, not the source system's. For long-horizon point-in-time correctness, the pipeline still needs CDC or event history stored as data. Schema management at the front door Because schemas change, ingestion needs a policy for what happens when they do. The useful tool here is a schema registry, a service that stores versioned schemas for each data stream and checks proposed changes against compatibility rules. Confluent Schema Registry is the most widely deployed, used with Avro, Protobuf or JSON Schema; alternatives exist from cloud vendors and open-source projects such as Apicurio. The registry enforces a compatibility mode for each subject. Backward compatibility means consumers using the new schema can read data written with the old one, which permits deleting fields and adding optional fields with defaults. Forward compatibility means consumers using the old schema can read data written with the new one. Full compatibility requires both. A producer attempting to register an incompatible schema is rejected, ideally in its CI pipeline before deployment rather than at runtime. This turns a class of silent failures into loud ones. A field rename, which is a delete plus an add, will fail compatibility under most settings, forcing a conversation between producer and consumer. What schema registries cannot do is enforce meaning. A field whose type stays int64 but whose unit changes from cents to dollars passes every compatibility check. Semantic guarantees need the additional tools of Chapter 7. Idempotence and exactly-once in practice Every ingestion pipeline eventually retries. A network call times out after the server has actually processed it; a job fails after writing half its output and is rerun; a consumer crashes after processing a message but before recording that it did. Each retry risks duplicates. The robust answer is not to prevent retries but to make them harmless: design every write to be idempotent, so that applying it twice has the same effect as applying it once. In practice this means giving every record a stable unique identifier at the source, an event ID or a primary key plus log position, and writing with upsert or merge semantics keyed on that identifier rather than with blind appends. Batch jobs should overwrite whole partitions atomically rather than appending to them, so a rerun replaces its own previous output. These are unglamorous habits, and they eliminate a large fraction of the duplicate-record problems that otherwise surface as inflated counts and biased training sets. Streaming systems advertise "exactly-once" processing, and Chapter 5 explains what Kafka's version of that guarantee does and does not cover. For now the practical point is that end-to-end exactly-once behaviour, from source to final table, almost always depends on idempotent writes at the sink, whatever the messaging layer promises. What good ingestion buys A well-designed ingestion layer does not make data correct. It makes data recoverable. It preserves enough history to reconstruct the past, enough metadata to trace any record to its origin, enough schema discipline to turn structural changes into explicit decisions and enough idempotence to make retries safe. Everything downstream depends on these properties. The next chapter takes up the one that ML pipelines get wrong most often and most expensively: time. Chapter 3: Time Is the Hardest Column If one idea in this booklet deserves to be remembered above the others, it is this: every training example is a reconstruction of a moment in the past, and it is only valid if it contains exactly what was knowable at that moment. Nothing later. Nothing that arrived late but was stamped early. Nothing computed from a version of the data that did not exist yet. Get this wrong and the model learns from information it will never have in production, evaluates beautifully offline and underperforms the day it ships. Time is hard in data engineering because a single record carries several different times, and pipelines routinely confuse them. It is hard in machine learning specifically because the confusion does not cause errors; it causes optimism. The many clocks of a record Take a single purchase on an e-commerce site. The customer taps "buy" on a phone at 21:58:03 local time. The phone, briefly offline, sends the event at 22:14:40. The collection endpoint receives it at 22:14:41 UTC-adjusted. It lands in Kafka with a broker-assigned timestamp a few milliseconds later. A stream processor handles it at 22:14:43. The nightly batch that loads it into the warehouse runs at 02:00 the next day. Three weeks later, the customer returns the item, and the order record is updated to reflect a refund. That one purchase has at least six meaningful timestamps: · Event time: when the purchase actually happened, 21:58:03 in the customer's time zone. · Device time: what the phone's clock said, which may be wrong. · Ingestion time: when the platform first received it. · Processing time: when any given pipeline stage handled it. · Availability time: when it became queryable in the system that would be used at prediction time. · Revision time: when a later fact, here the refund, changed what we know about it. Analytics can often get away with one of these, usually event time. Machine learning cannot, because the question a training pipeline must answer for every feature value is not "when did this happen?" but "when could the model have known this?" That is availability time, and it is almost never stored explicitly. Leakage: learning from the future Leakage is the use, in training, of information that would not be available at prediction time. It takes several forms, all of them common. Target leakage is when a feature is a consequence of, or a proxy for, the label. A model predicting whether a hospital patient will develop sepsis that includes, as a feature, whether a sepsis-specific antibiotic was administered, has learned that doctors treat sepsis, not how to detect it early. A churn model that includes "account status" where cancelled accounts were already marked inactive has learned to read the answer. These are conceptual errors more than engineering ones, but engineering makes them easy: a wide denormalised table with hundreds of columns invites someone to throw them all in. Temporal leakage is the engineering form, and it is subtler. The feature is legitimate in principle, but it was computed using data from after the prediction moment. Consider a fraud model that uses "number of transactions on this card in the last 24 hours." In training, this is computed from the warehouse, where every transaction is present. If the computation is a simple group-by over a day boundary instead of a window ending exactly at the transaction being scored, then for a transaction at 09:00 the feature includes transactions from 09:00 to midnight, which are in the future. Worse, the card's later transactions are likely to include the fraudster's subsequent attempts, so the leaked feature is strongly predictive. Offline accuracy soars. In production, at 09:00, those later transactions do not exist, and the feature is much weaker. Revision leakage comes from using the current state of mutable data. A customer's address, credit limit or account tier, read from today's table, may differ from what it was when the historical prediction would have been made. If the field was updated as a result of the outcome being predicted, for instance a credit limit lowered after a default, the leak is direct. If it was updated for unrelated reasons, the leak is noise, but noise that makes training data cleaner than production data in ways that are hard to characterise. Split leakage is leakage between training and evaluation sets. Randomly splitting time-series data into train and test means the model is trained on Tuesday and tested on the Monday before it, learning patterns that interpolate rather than forecast. Randomly splitting records that share an entity, such as several transactions from the same customer, lets the model memorise entity-specific quirks that then appear to generalise. For almost every production ML problem, evaluation sets should be split by time, with all evaluation data strictly later than all training data, and often by entity as well. The shared signature of all leakage is that offline metrics are better than online metrics, sometimes dramatically so. When a model's production performance is markedly below its validation performance, leakage should be the first hypothesis, before distribution shift and before any modelling explanation. Point-in-time correctness The remedy for temporal and revision leakage has a name: point-in-time correctness. A training example is point-in-time correct if every feature value in it is the value that would have been retrieved by the production system at the example's timestamp. Mechanically, this means a training set is not built by joining current tables. It is built from two inputs. The first is a spine: a list of entities and timestamps at which predictions would have been made, along with the label for each. For a fraud model, the spine is every historical transaction with its fraud outcome. For a churn model, it might be every customer on the first of each month, with a label for whether they churned in the following thirty days. The second input is the history of each feature: not its current value, but a log of every value it has taken and when that value became available. Joining these requires what is called a point-in-time join or an as-of join. For each row in the spine, and for each feature, the join selects the most recent feature value whose availability timestamp is at or before the spine row's timestamp. Not the nearest value, which might be in the future; the latest value that was already known. In SQL this can be expressed with a window function that ranks feature rows per spine row, or with a lateral join. Several engines now support it directly; DuckDB, Snowflake and ClickHouse, among others, offer an ASOF JOIN construct, and pandas has had merge_asof for years. A typical form looks like this: SELECT s.transaction_id, s.event_ts, s.label, f.txn_count_24h FROM spine s ASOF LEFT JOIN card_features f ON s.card_id = f.card_id AND s.event_ts >= f.available_ts; The essential detail is available_ts rather than event_ts on the feature side. If the feature was computed by a batch job that ran at 02:00, then a value describing yesterday became available at 02:00 today, not at midnight. A spine row at 01:00 must see the previous day's value. Using event time instead of availability time on the feature side reintroduces a small leak, and small leaks in high-frequency features can matter a great deal. This is one of the main functions of a feature store, which Chapter 4 discusses: it records feature values with their timestamps and performs point-in-time joins correctly, so that individual data scientists do not have to reimplement the logic, and get it subtly wrong, in each project. Bitemporal thinking The most rigorous way to handle revisions is to store data bitemporally, with two time dimensions for each fact. Valid time is when the fact was true in the world. Transaction time, sometimes called system time or knowledge time, is when the system learned it. A customer's address change effective from the first of May but entered into the system on the tenth of May has a valid time of the first and a transaction time of the tenth. For a model making predictions on the fifth of May, the correct address is the old one, because on the fifth the system did not yet know about the change. A table that records only valid time would, in a training reconstruction, wrongly supply the new address. A bitemporal table can answer the question precisely: what did we believe, as of the fifth, about where the customer lived? Few operational systems store data bitemporally, and it would be unrealistic to demand it. But CDC, described in Chapter 2, provides the raw material for it: each change event carries the commit time, which is transaction time. A pipeline that retains the full change history can derive, for any entity and any past moment, what the database contained. This is a strong argument for CDC over periodic snapshots in ML platforms. Snapshots taken nightly can only answer the question at nightly granularity. Financial services have long cared about this distinction because regulators ask what a firm knew and when. ML teams should care for the same reason, applied to their own models. Labels have timestamps too Labels raise their own timing problems. Many labels are not known at the moment of prediction, nor shortly after. Whether a loan defaults is known months or years later. Whether a transaction was fraudulent may be determined weeks later when a chargeback arrives. Whether a recommended item led to a purchase depends on an attribution window. This creates two practical issues. First, recent data is systematically mislabelled. If a fraud label is assigned when a chargeback arrives, then transactions from the last few weeks are disproportionately labelled "not fraud" simply because their chargebacks have not arrived yet. Training on them teaches the model that recent fraud looks legitimate. The fix is to define a label maturity window, such as only including transactions old enough that the great majority of their eventual chargebacks would have arrived, and to exclude or downweight anything younger. The right window depends on the domain and should be estimated from historical data on how long labels take to settle. Second, labels can change. A transaction labelled legitimate may later be reclassified after investigation. A content moderation decision may be overturned on appeal. If the label table is mutable and overwritten, the training set changes each time it is regenerated, and a model trained last month cannot be reproduced. Labels should be stored with their own history, so that a training set can be defined as "labels as known at time T," fixed and reproducible. Backfills: rewriting history carefully Sooner or later, a new feature is invented and the team wants to train with it. Training requires history, so the feature must be computed for the past, a process called backfilling. Backfills are where point-in-time correctness most often breaks, for a reason that is easy to miss. When a feature is computed live, by a streaming or scheduled job, it sees data as it arrives, including the arrival delays, the missing records and the late corrections. When it is backfilled, it is computed retrospectively over the warehouse, where all of those records have long since arrived and been corrected. The backfilled history is therefore cleaner and more complete than the live feature will ever be. A model trained on backfilled features learns from a world slightly better informed than the one it will operate in. There is no perfect fix. Several mitigations help. Backfill logic can deliberately simulate arrival delay, excluding records whose ingestion timestamp is later than the simulated computation time, which requires that ingestion timestamps were recorded, another argument for keeping that metadata at the raw layer. Teams can compare the distribution of backfilled values over a recent period with the live values actually computed over the same period, which directly measures the gap. And once a feature has been running live for long enough, models can be retrained on the logged live values rather than the backfill. The most robust approach, advocated in Google's "Rules of Machine Learning" and adopted by many large platforms, is to log features at serving time: whenever the production system makes a prediction, record the exact feature vector it used. Those logs become training data that is point-in-time correct by construction, because they are literally what the model saw. The drawback is that new features have no logged history until they have been deployed for a while, so logging complements rather than replaces backfilling. Testing for leakage Because leakage makes models look better, nobody goes looking for it unless they have a reason. It is worth building tests that go looking routinely. The most effective single test is the gap between offline and online performance. Before full deployment, run the model in shadow mode, scoring live traffic without acting on the scores, and once labels arrive, compare its live performance with its offline evaluation over a comparable period. A large gap is not proof of leakage, since distribution shift can cause it too, but it is the strongest available signal and should trigger an investigation before the model is trusted. A second test is feature importance inspection with suspicion. When a single feature dominates the model, or a feature that seems only loosely related turns out to be highly predictive, ask how it is computed and when its values are populated. Leaking features are often the most important ones, because information from the future is extremely predictive. A column such as "last_updated_at" or "status_reason" ranking near the top of a churn model's importance list is a warning sign: these fields are frequently written as a consequence of the outcome. A third test is temporal holdout with a gap. Train on data up to a cutoff, skip a period at least as long as the longest feature window or label maturity delay, and evaluate on data after the gap. If performance drops sharply compared with an evaluation that has no gap, some information is bleeding across the boundary. A fourth, and the most thorough, is reconstruction from logs. For a sample of real predictions made in production, take the feature vector that was actually served, which requires serving-time logging, and compare it with the feature vector the training pipeline would generate for the same entity and timestamp. Systematic differences reveal both leakage, where the training vector contains information the served one lacked, and skew. This test is the empirical definition of point-in-time correctness, and a platform that can run it routinely has largely solved the problem. These tests are cheap compared with the cost of a model that underperforms for months while everyone looks for the cause in the wrong place. Time zones, clocks and other indignities A few practical rules prevent a surprising share of time-related bugs. Store all timestamps in UTC, with explicit time zone information, and convert to local time only for features that genuinely depend on local time, such as hour of day for a user, using the user's own time zone rather than the server's. Daylight saving transitions produce days with twenty-three and twenty-five hours; any feature defined as "per day" should be checked against them. Never trust client device clocks for anything that matters. Record both device time and server receipt time, and use server time for ordering and windowing unless there is a specific reason not to. Device times that are wildly wrong, such as dates in 1970 or decades in the future, are common enough in mobile telemetry that every pipeline should expect them. Define windows precisely, and define them once. "Last seven days" can mean the last 168 hours from now, the last seven calendar days including today, or the last seven complete calendar days. Each yields different values. If training uses one interpretation and serving another, that is training-serving skew, introduced by an ambiguity in natural language. Writing the definition once, in code that both paths share, is the only reliable remedy, and it leads directly to the subject of the next chapter. Chapter 4: Feature Stores: One Definition, Two Paths A feature is a measurable property of an entity that a model uses as input: a customer's average order value over ninety days, a card's transaction count in the past hour, a driver's acceptance rate this week, the embedding of a product's description. Features are where raw data becomes something a model can learn from, and the code that computes them is, in most mature ML systems, larger and more consequential than the code that trains models. A feature store is infrastructure for managing that code and its outputs. The term has been stretched by vendors to cover almost anything, so it is worth being precise about what problem the idea was invented to solve, what a feature store actually consists of and when a team needs one. The problem: two pipelines that should be one Before feature stores, a typical ML project went like this. A data scientist wrote SQL or a pandas notebook that computed features from the warehouse, joined them to labels, trained a model and achieved good offline results. To put the model into production, an engineer then had to make the same features available at prediction time, usually within tens of milliseconds, for a single entity, in a service that could not run warehouse queries. So the engineer reimplemented the feature logic: in Java or Go inside the serving application, or in a stream processor writing to a key-value store such as Redis or Cassandra. There were now two implementations of every feature, written by different people in different languages against different data sources. They were supposed to produce identical values. They rarely did. The batch version computed a ninety-day average over calendar days; the online version over a rolling window. The batch version treated null as zero; the online version skipped nulls. The batch version read a deduplicated table; the online version read the raw event stream, duplicates and all. Each discrepancy was a source of training-serving skew, and because the model had never seen correctly computed serving features, there was no baseline to detect the skew against. There were other costs. Features were reinvented in every project, because there was no catalogue of what existed. Point-in-time joins were rewritten, often incorrectly, by every data scientist who built a training set. Nobody could say which models depended on which features, so changing a feature was dangerous. Uber described this problem publicly in a 2017 engineering blog post introducing Michelangelo, its internal ML platform. Michelangelo included a shared feature store where teams could register features once and use them for both training and serving, and the post is widely credited with popularising the term. Similar internal systems existed at other large companies, and over the following years the pattern moved into open source, with Feast, originally developed by the Indonesian technology company Gojek together with Google Cloud and released in 2019, and into commercial products from Tecton, founded by members of the Michelangelo team, Hopsworks and the major cloud providers. In 2025 Databricks announced its acquisition of Tecton, folding one of the most prominent independent feature platforms into a larger data platform, a sign of how central real-time feature serving has become to the large vendors' plans. What a feature store actually is Stripped of marketing, a feature store has four components. Different products emphasise different parts, and some teams assemble their own from simpler pieces. A feature registry. This is a catalogue of feature definitions: each feature's name, the entity it describes, its data type, the code or query that computes it, its source data, its owner and its freshness expectations. The registry is the single source of truth about what a feature means. It is what turns "customer_avg_order_90d" from a column name into a defined, versioned, discoverable asset. In tools like Feast, these definitions are written as code and live in a repository, reviewed like any other code. An offline store. This holds the full history of feature values, with timestamps, for training. It is usually a warehouse or lakehouse table: BigQuery, Snowflake, Redshift, or Parquet files under an open table format. The essential capability is the point-in-time join described in Chapter 3. Given a spine of entities and timestamps, the offline store returns, for each row, each feature's value as of that moment. An online store. This holds only the latest value of each feature per entity, optimised for low-latency lookup by key. Redis, DynamoDB, Cassandra, Bigtable and similar systems are typical. At prediction time, the serving application asks for the features of a given customer or card, and gets them in a few milliseconds. Materialisation and computation. This is the machinery that keeps the two stores populated and consistent. Batch jobs compute features from warehouse data and write them to both stores. Streaming jobs compute fresher features from event streams and write them, typically to the online store first and the offline store as a log. Some feature stores also support on-demand features, computed at request time from data in the request itself, such as the distance between a transaction's location and the cardholder's home, which cannot be precomputed because the transaction location is only known at that instant. The crucial property is that a feature has one definition and that definition is used to populate both stores. The online value for a customer right now and the offline value for that customer at any past moment are produced by the same logic. This does not eliminate skew completely, since streaming and batch execution can still differ in late-data handling, but it removes the largest source of it: two people writing the same feature twice. Freshness and the cost of being real-time Features differ enormously in how fresh they need to be, and that requirement drives architecture and cost more than any other factor. Table 2 groups features into broad freshness tiers. Table 2. Feature freshness tiers and how each is typically computed. Tier Typical staleness Computed by Example feature Batch Hours to a day Scheduled warehouse job Customer lifetime spend Near real-time Seconds to minutes Stream processor Card transactions in last hour On-demand Computed per request Serving-time function Distance from home location Batch features are cheap and easy. A scheduled SQL job computes them nightly, writes them to the offline store and pushes the latest values to the online store. Most features in most models are batch features, and most should be: customer tenure, historical averages, product attributes and slow-moving aggregates gain little from being fresher than a day. Streaming features are expensive. They require a stream processor running continuously, holding state for every entity, handling late and out-of-order events, and writing to the online store with low latency. Chapters 5 and 6 explain what this involves. The payoff is large for some problems, especially fraud detection, where the most predictive signals are about what has happened in the last few minutes, and real-time recommendation, where a user's last few clicks reveal current intent better than months of history. It is small for others, and many teams adopt streaming features because they sound modern rather than because their model measurably benefits. A sound rule is to start with batch features, measure the value of freshness by experiment, for instance by training with features artificially lagged by various amounts and comparing offline performance, and invest in streaming only for the features where freshness demonstrably matters. On-demand features sit in a separate category because they depend on the request itself. They are computed by a function, ideally registered in the feature store so that the same function can be applied to historical requests to produce training data. If that function is reimplemented separately for training, the old skew problem returns. Feature design for reuse and safety A feature store makes features shareable, which raises the stakes of designing them well. A few practices are worth adopting regardless of tooling. Name features descriptively and include the window and aggregation in the name: card_txn_count_1h, not velocity. Ambiguous names are the root of many semantic errors, because two teams can both believe they know what velocity means. Define features on stable, well-understood entities. A feature keyed on customer_id is only reusable if every team agrees on what a customer is. In many organisations, they do not: marketing's customer, billing's account and the product's user are different things, joined by mappings that change over time. Settling entity definitions is a prerequisite for a useful feature store, and often the hardest part of adopting one. Record the expected range, null rate and distribution of each feature when it is registered, and validate against them on every computation. A feature store that serves whatever its pipelines write is a faster way to distribute bad data. Chapter 7 develops this. Track which models consume which features. This lineage turns a feature change from a guessing game into a known set of affected consumers. It also makes it possible to deprecate features safely, which matters because feature stores accumulate dead features as models are retired. Version features rather than mutating them. If the definition of customer_avg_order_90d changes, for instance to exclude refunded orders, existing models were trained on the old definition and will see skew if the online value silently switches. Either create a new feature, customer_avg_net_order_90d, or version the definition explicitly and let models pin the version they were trained on. A worked example: features for a fraud model It helps to see these ideas applied to one model. Consider a card-not-present fraud model for an online retailer, which must score each payment attempt within about fifty milliseconds, before the payment is sent for authorisation. The model's inputs fall naturally into the three freshness tiers. Batch features describe the customer and the card over long horizons: account age, number of past orders, historical chargeback count, the usual shipping country, the median order value over the last six months. These change slowly and are computed nightly from the warehouse, materialised to the online store keyed by customer and by card. Streaming features describe the last few minutes and hours: the number of payment attempts on this card in the last ten minutes, the number of distinct cards used from this device in the last hour, the number of failed attempts on this account today. Fraud tends to arrive in bursts, as an attacker tests stolen card numbers or tries several cards on one account, and these velocity features capture it. They are computed by a stream processor reading the payments topic, keyed by card, device and account, and written to the online store within a second or two of each event. On-demand features describe the request itself in relation to stored history: whether the shipping address differs from any previous address, the distance between the IP address's estimated location and the billing address, the ratio of this order's value to the customer's median. These cannot be precomputed because the request has never been seen before. They are computed by registered functions at scoring time, combining request fields with batch features fetched from the online store. To train the model, the team builds a spine of every historical payment attempt, with its timestamp and its matured fraud label. The offline store supplies, for each attempt, the batch features as of the last nightly run before it, the streaming features as logged at that moment by the streaming job, and the on-demand features by applying the same registered functions to the stored request payloads. Each source of features is aligned by availability time. Several design decisions in this example are where real systems go wrong. If the streaming features are backfilled from the warehouse rather than taken from logged values, they will be more complete than live ones, as Chapter 3 explained. If the on-demand distance calculation is written once in Python for training and again in Java for serving, it will drift. If the nightly batch job runs late one day and the online store serves two-day-old values, the model will not know unless freshness is tracked. A feature store, properly used, provides answers to each of these; used carelessly, it is a convenient place to store the same mistakes. Do you need one? The honest answer for many teams is: not yet. A feature store adds infrastructure, operational burden and a new abstraction for everyone to learn. Its benefits scale with the number of models, the number of teams sharing features and the presence of real-time serving. A team with one or two models, trained and scored in batch, where predictions are written to a table rather than served by an API, gets most of the value from simpler discipline. It needs feature logic written once in a shared library or SQL module, point-in-time training set construction done carefully, and feature values validated. There is no online path, so there is no online-offline skew. A team serving models in real time, but only a few of them, can often get by with a shared feature computation module used by both the training pipeline and the serving service, plus logging of served features. This captures the core benefit, a single definition, without a separate platform. The case for a dedicated feature store becomes strong when several conditions hold together: multiple models served online with low latency requirements, multiple teams that would benefit from sharing features, streaming features that must be consistent across training and serving, and enough history of skew incidents to justify the investment. Large technology companies hit all of these early. Many organisations hit them gradually, and the right time to adopt a feature store is when the cost of duplicated feature logic and skew investigations clearly exceeds the cost of operating one. Embeddings and vector features A growing share of features are not scalars but vectors: embeddings of text, images, users or items, produced by neural networks and consumed by other models or by retrieval systems. These raise questions that classical feature stores were not designed for. Embeddings are tied to the model that produced them. An item embedding from version 3 of an encoder is not comparable with one from version 4; mixing them silently corrupts every downstream similarity computation. Any store of embeddings must therefore record the producing model's version alongside each vector and must handle re-embedding the whole corpus when the encoder changes, which can be expensive for large catalogues. Embeddings are also queried differently. A scalar feature is looked up by key. An embedding is often used for nearest-neighbour search: find the items closest to this user's vector. That requires an approximate nearest-neighbour index, provided by vector databases and by vector extensions in general-purpose databases such as pgvector for PostgreSQL. Several feature store products have added vector support, and the boundary between feature stores and vector databases is blurring. The data engineering principles do not change, however. Embeddings need a single definition, here the model version and preprocessing, used consistently for training and serving. They need point-in-time correctness: a recommendation model trained on last year's interactions should use the item embeddings that existed then, or at least be aware that it is not. And they need validation, because an encoder that starts producing degenerate vectors, collapsed toward a single point or filled with NaN, will not crash anything; it will just make every similarity meaningless. Chapter 8 returns to these pipelines in the context of language models. Whatever the form of the feature, the requirement that matters most is the same. There must be one definition, executed identically for training and serving, with its history preserved. Everything else a feature store offers is convenience built around that core. Delivering fresh features in real time, however, requires a reliable way to move events, and that is the subject of the next chapter. Chapter 5: Apache Kafka as the Telemetry Backbone When a machine learning system needs to react to the world within seconds, whether scoring a payment before it is authorised, updating recommendations while a user is still browsing or flagging a failing machine on a factory floor, it needs a way to move events from where they happen to where they are processed, reliably and in order, at whatever volume the world produces. For most organisations that do this at scale, the answer is Apache Kafka or a system that speaks its protocol. Kafka was built at LinkedIn around 2010 by Jay Kreps, Neha Narkhede and Jun Rao, open-sourced in 2011 and became a top-level Apache project in 2012. Kreps's 2013 essay "The Log: What every software engineer should know about real-time data's unifying abstraction," published on LinkedIn's engineering blog, remains the clearest statement of the idea behind it, and his short book I Heart Logs expands it. The idea is that an append-only, ordered, durable log of events is a natural integration point for an entire organisation's data. Producers append to it. Any number of consumers read from it, each at its own pace, each able to replay from any point. The log becomes the source of truth from which databases, caches, search indexes, warehouses and, for our purposes, feature stores are all derived. This chapter explains Kafka's model in enough depth to make sound design decisions for ML telemetry. It is not an operations manual, but the design choices it covers, around partitioning, ordering, retention and delivery semantics, are ones that ML pipelines frequently get wrong. The core model Kafka organises events into topics, such as payments, page_views or sensor_readings. Each topic is divided into partitions, and each partition is an ordered, append-only sequence of records, each identified by a monotonically increasing offset. Partitions are the unit of parallelism and the unit of ordering: Kafka guarantees that records within a single partition are read in the order they were written, and makes no ordering guarantee across partitions. A record consists of an optional key, a value, a timestamp and optional headers. The key determines which partition the record goes to; by default, the producer hashes the key and takes it modulo the number of partitions. All records with the same key therefore land in the same partition and are ordered relative to each other. Records with no key are spread across partitions for load balance. Partitions are stored on brokers, the servers that make up a Kafka cluster, and each partition is replicated to several brokers for durability. One replica is the leader, which handles writes; the others are followers that copy from it. If the leader's broker fails, a follower that is fully caught up, a member of the in-sync replica set, takes over. Consumers read records from partitions and track their position by committing offsets. Consumers are organised into consumer groups: within a group, each partition is assigned to exactly one consumer, so a group of ten consumers reading a topic with thirty partitions processes three partitions each, in parallel. Different groups read independently. The fraud scoring service, the feature pipeline and the warehouse loader can all consume the same payments topic, each in its own group, each at its own pace, without interfering. Kafka retains records for a configured period, or up to a configured size, regardless of whether they have been consumed. This is the property that most distinguishes it from a traditional message queue, where messages are deleted once acknowledged. A consumer that falls behind can catch up. A new consumer can start from the beginning of retained history. A consumer whose processing logic had a bug can be reset to an earlier offset and reprocess. Recent evolution Kafka has changed substantially in recent years, and older descriptions are misleading in a few respects. Historically, Kafka depended on Apache ZooKeeper, a separate distributed coordination service, to store cluster metadata. KIP-500, a Kafka Improvement Proposal first published in 2019, replaced this with KRaft, a Raft-based consensus protocol built into Kafka itself. KRaft became production-ready in the 3.x series, and Kafka 4.0, released in March 2025, removed ZooKeeper support entirely. Kafka 4.0 also made generally available a new consumer group rebalance protocol, defined in KIP-848, which moves partition assignment to the broker and greatly reduces the "stop-the-world" pauses that used to occur whenever consumers joined or left a group. Those pauses were a real problem for latency-sensitive ML scoring services that autoscale. Another long-requested feature, KIP-932, adds share groups, which let several consumers cooperatively process records from the same partition with per-record acknowledgement, giving Kafka queue-like semantics. It appeared in early access in Kafka 4.0, moved to preview in 4.1 in September 2025, and has continued to be refined in the 4.2 and 4.3 releases of 2026. For ML workloads where each event is an independent unit of work, such as running an expensive model inference per document, share groups loosen the old coupling between partition count and consumer parallelism. Teams should check the status of the feature in their own Kafka version before depending on it, because the per-record model gives up the per-partition ordering that most feature pipelines need. Finally, the Kafka protocol has become a de facto standard implemented by other systems. Redpanda, WarpStream, Amazon MSK, Confluent Cloud, Azure Event Hubs' Kafka endpoint and others accept Kafka clients. The design principles in this chapter apply to all of them, though operational characteristics differ. Keys, partitions and the ordering you actually need The single most consequential design decision for a Kafka topic feeding ML features is the choice of key, because it determines what is ordered relative to what. Suppose a topic of card transactions feeds a stream processor that computes, for each card, a count of transactions in the last hour. For that count to be correct, the processor must see every transaction for a given card, and it helps greatly if it sees them in order. Keying the topic by card ID guarantees both: all of a card's transactions go to one partition, are consumed by one processor instance and arrive in the order they were produced. The processor can maintain each card's state locally without coordinating with other instances. If the topic were keyed by merchant ID instead, a card's transactions would scatter across partitions, be processed by different instances and arrive in an order that depends on the relative lag of each partition. Computing per-card features would require repartitioning the stream by card ID first, which stream processors can do but which adds a network shuffle, an intermediate topic, and latency. A topic is keyed once, and it serves many consumers who may want different groupings. The usual approach is to key by the entity that the most important consumer aggregates on, and to let other consumers repartition. For telemetry from devices, the device ID is almost always the right key. For user activity, the user or session ID. For CDC streams, the table's primary key, so that all changes to a row stay in order, which is essential for reconstructing state correctly. Two pitfalls follow from keying. Hot keys occur when one key carries vastly more traffic than others, such as a single very large merchant, a bot generating millions of page views or a misbehaving sensor. Its partition becomes a bottleneck and its consumer falls behind while others idle. Mitigations include salting hot keys, by appending a suffix to spread them across several partitions at the cost of per-key ordering, or isolating known heavy hitters into separate topics. Changing the partition count remaps keys to partitions, because the hash is taken modulo the count. Records for a given key written before the change may be in a different partition from those written after, breaking ordering at the transition. It is far better to provision enough partitions at creation for expected growth than to increase them later. Delivery guarantees, precisely Distributed messaging offers three classes of delivery guarantee. At-most-once means a record may be lost but is never duplicated. At-least-once means a record is never lost but may be duplicated. Exactly-once means each record affects the result exactly one time. For ML pipelines, losses bias features and labels downward and duplicates bias them upward; neither is acceptable for counts, sums or anything used as a label. On the producer side, Kafka's durability depends on the acks setting. With acks=all, a write is acknowledged only when all in-sync replicas have it, which, combined with a topic setting of min.insync.replicas of at least two, protects against loss when a broker fails. Producers retry on transient errors, and a retry after a lost acknowledgement could write a duplicate. Idempotent producers, enabled by default in modern Kafka clients, prevent this: each producer has an ID and each record a sequence number, and brokers discard duplicates within a partition. On the consumer side, the question is when to commit the offset relative to processing. Commit before processing, and a crash after the commit loses the record: at-most-once. Commit after processing, and a crash before the commit reprocesses it: at-least-once. Most pipelines choose at-least-once and make processing idempotent. Kafka's transactions, introduced in version 0.11 in 2017, provide exactly-once semantics within Kafka. A processor that reads from input topics and writes to output topics can do both, and commit its input offsets, in one atomic transaction. Consumers configured with isolation.level=read_committed see only committed transactional writes. Stream processing frameworks such as Kafka Streams and Apache Flink use this to provide exactly-once processing for pipelines whose inputs and outputs are all Kafka topics. The boundary matters. Exactly-once within Kafka does not extend automatically to external systems. When a feature pipeline writes to Redis or to a database, the write to Redis is not part of the Kafka transaction. If the pipeline crashes after writing to Redis but before committing its offset, it will reprocess the record and write again. Whether that causes harm depends on the write. Setting a feature to a value is idempotent; incrementing a counter is not. This is why the advice from Chapter 2 recurs: design sink writes to be idempotent, for example by writing the full computed aggregate rather than an increment, or by keying writes on event IDs, and then at-least-once delivery yields exactly-once results. Retention, compaction and replay Retention policy determines how far back consumers can go, and for ML it deserves more thought than it usually gets. Time- or size-based retention deletes old log segments after a set period, commonly seven days by default. This suits pipelines that only need to recover from short outages. It does not support rebuilding a feature from history after its definition changes, unless history is also kept elsewhere. Log compaction retains, for each key, at least the latest record, discarding older records with the same key. A compacted topic is effectively a changelog that always contains the current state of every key. This is ideal for reference data, such as the latest profile per user, and for the state backing stream processors, but it destroys history, which is exactly what point-in-time feature computation needs. Tiered storage, defined in KIP-405 and production-ready in Kafka 3.9, offloads older log segments to object storage while keeping them readable through the normal Kafka API. This makes long retention, months or years, affordable. For ML platforms it opens the possibility of using Kafka itself as the historical record from which features are backfilled, so that streaming and backfill read the same events through the same code. In practice, most platforms also sink every topic to the lakehouse, landing raw events in the bronze layer described in Chapter 2. The lakehouse copy is cheaper to query in bulk and integrates with batch tools; the Kafka copy supports streaming replay. Both should carry the same event identifiers and timestamps so they can be reconciled. Designing telemetry topics for machine learning Several practices make Kafka topics markedly more useful as sources of ML data. Carry event time in the payload. Kafka records have a timestamp field, which by default is set by the producer at send time and can be configured to be set by the broker on append. Neither is necessarily the time the event occurred. Put the true event time, and for device telemetry the device's own reported time, in the payload as explicit fields. Downstream windowing, discussed in Chapter 6, depends on it. Give every event a unique, stable ID generated at the source. It enables deduplication anywhere downstream, which is the foundation of idempotent processing. Use a schema registry with an enforced compatibility mode for every topic, as Chapter 2 described. Schemaless JSON topics are convenient for the first producer and painful for every consumer thereafter. Prefer events that state facts to events that state changes. An event that says "balance changed by minus 40" requires the consumer to have seen every previous event to know the balance. An event that says "balance is now 160, after a debit of 40" is self-contained. Self-contained events are more robust to loss, easier to backfill from and easier to validate. Separate topics by meaning, not by convenience. A single events topic carrying every event type from an application, distinguished by a type field, forces every consumer to read and discard most of it, and makes per-type schemas and retention impossible. Separate topics for separate event types, with clear ownership, scale better. Route bad records to a dead-letter topic rather than dropping them or halting. A consumer that cannot parse or validate a record should write it, with the error, to a separate topic for inspection, and continue. This makes data problems visible and countable; a rising dead-letter rate is one of the most useful early warnings a pipeline can emit. Monitor consumer lag. The difference between the latest offset in a partition and a consumer group's committed offset is its lag. For a feature pipeline, lag is staleness: if the processor is ten minutes behind, the online features are ten minutes old, and a fraud model that assumes fresh velocity features is being fed stale ones. Lag per partition, not just in aggregate, should be monitored and alerted on, and the serving system should ideally know how fresh its features are. Sizing partitions and planning for replay Two capacity questions recur in ML telemetry design, and both are easier to answer at the start than to fix later. The first is how many partitions a topic needs. Because a partition is consumed by at most one member of a consumer group, the partition count caps the parallelism of every consumer of that topic. A feature pipeline that needs twenty parallel workers to keep up at peak load needs at least twenty partitions. The practical approach is to estimate peak throughput per partition that a single consumer instance can sustain, including the cost of whatever processing it does, and divide expected peak volume by that, then add generous headroom for growth, since adding partitions later breaks key ordering at the transition. Too many partitions has costs as well, in broker memory, file handles, longer leader elections and more end-to-end latency for small batches, so the answer is "enough with room to grow," not "as many as possible." Confluent's documentation and Kafka's own operations guidance discuss the trade-offs in more depth. The second question is how fast the pipeline can replay history. A feature definition change, a bug fix or a new model often requires reprocessing weeks or months of events. If a stream processor normally runs at twice real-time capacity, catching up on thirty days of history takes fifteen days, during which the new feature is unavailable. Replay speed is bounded by partition count, consumer resources and the throughput of the sink, and the online store in particular may not tolerate a sudden flood of writes. Teams that expect to replay should plan for it explicitly: provision the ability to run a separate replay job with more resources, write its output to a fresh location rather than the live store, and switch over once it has caught up. Some teams instead compute historical features with a batch engine over the lakehouse copy of the topic, and use streaming only from the switch-over point forward, accepting the consistency risks discussed in Chapter 6 in exchange for speed. Replay also exposes a subtlety of ordering. When a consumer reads a backlog, records from different partitions arrive in an order determined by how quickly each partition is read, not by event time. A pipeline that joins two topics, or aggregates across keys, may see events in a very different interleaving during replay from the one it saw live. Pipelines that window by event time and use watermarks, as the next chapter describes, are robust to this. Pipelines that rely on processing order are not, and will produce different features on replay from those they produced live. What Kafka does not do Kafka moves and stores events. It does not validate their content beyond schema, compute aggregates, join streams or detect that a sensor has started reporting nonsense. It guarantees ordering only within a partition, and only in the order the producer wrote, which is not necessarily the order events happened. Its exactly-once guarantees stop at its own boundary. These limits are not defects; they reflect a clean separation of concerns. Turning a stream of events into features, correctly and in real time, is the job of a stream processor, and that is where the most difficult questions about time return in a new form. Chapter 6: Stream Processing: Features in Motion A stream of events is not yet a feature. A fraud model does not want the raw sequence of a card's transactions; it wants to know how many there were in the last ten minutes, how many distinct merchants were involved, how the largest amount compares with the card's typical amount. A predictive maintenance model does not want every vibration reading from a motor; it wants the rolling mean and variance over the last hour, and how they compare with yesterday's. Turning streams into features like these, continuously and correctly, is the work of a stream processor. The leading open-source engines are Apache Flink, which has become the most widely adopted general-purpose stream processor for stateful workloads; Kafka Streams, a library that runs inside an ordinary application and uses Kafka topics for its state backup; and Spark Structured Streaming, which extends Spark's batch model to micro-batches and continuous processing. Commercial and newer systems, including managed Flink offerings from cloud vendors and streaming databases such as RisingWave and Materialize, expose similar capabilities through SQL. The concepts in this chapter apply to all of them. The terminology mostly follows the influential 2015 paper by Tyler Akidau and colleagues at Google, "The Dataflow Model," and the subsequent book Streaming Systems by Akidau, Slava Chernyak and Reuven Lax, which remain the clearest explanations of the subject. Event time versus processing time, again Chapter 3 distinguished event time, when something happened, from processing time, when the pipeline handles it. In batch processing this distinction matters mainly for correctness of joins. In stream processing it becomes the central design question, because the processor must decide, continuously, when it has seen enough data to produce a result. Consider computing "transactions per card in each one-minute window." If the processor windows by processing time, assigning each event to the minute in which the processor happens to receive it, the logic is simple and the results are prompt. But they are wrong whenever events are delayed. A mobile payment that happened at 12:00:50 but reached the processor at 12:01:10 is counted in the wrong minute. During a network incident, or when the processor restarts and catches up on a backlog, whole minutes of events are counted in the minute the backlog was processed, producing bursts that never happened. A fraud model consuming those counts sees phantom velocity spikes. Windowing by event time assigns each event to the window in which it actually occurred, which is what the model needs. The result is correct, but it raises an obvious problem: when is a window finished? The processor cannot emit the count for 12:00 to 12:01 at 12:01, because events from that minute may still be in flight. It cannot wait forever either. Watermarks: deciding when you have waited long enough The solution adopted by Flink, Beam and others is the watermark. A watermark is a declaration, flowing through the stream alongside the data, that says: no more events with an event time earlier than T are expected. When the watermark passes the end of a window, the processor treats the window as complete and emits its result. Watermarks are estimates, not facts. In the simplest and most common form, the bounded-out-of-orderness strategy, the watermark is the maximum event time seen so far minus a fixed allowance, such as thirty seconds. This says, in effect, that events are assumed to arrive no more than thirty seconds late. If the assumption holds, results are complete. If an event arrives later than that, it is late data. Choosing the allowance is a trade-off between latency and completeness. A short allowance yields fresh features but drops or mishandles more late events. A long allowance yields more complete features but delays them. For a fraud model scoring transactions in real time, a feature that arrives five minutes late may be useless however complete it is. For a model scoring daily churn risk, a few minutes of delay is irrelevant and completeness matters more. The right allowance can be measured rather than guessed. Recording, for every event, the difference between its ingestion time and its event time produces a distribution of arrival delays per source. If the ninety-ninth percentile delay for server-side events is two seconds, a ten-second allowance is generous. For mobile telemetry the distribution typically has a long tail, with a minority of events arriving hours or days late from devices that were offline, and no reasonable allowance will capture them all. Watermarks are also per-partition in most engines, and the overall watermark is the minimum across partitions. A single idle partition, one that receives no events, can therefore hold back the watermark for the whole job, stalling every window. Engines provide idleness detection to handle this, and it needs to be configured; a stalled watermark looks, from outside, like a feature pipeline that has stopped producing output for no apparent reason. Handling late data Events that arrive after the watermark has passed their window can be handled in several ways, and the choice must be deliberate. They can be dropped, which is the default in many configurations. This is simple, and acceptable if late events are rare and the feature is robust to a small undercount. It should never be silent: the count of dropped late events should be a monitored metric. They can update the result. Flink's allowed lateness setting keeps window state for an additional period after the watermark passes and re-emits an updated result if late events arrive. Downstream consumers must then handle multiple results for the same window, by upserting rather than appending. For an online feature store keyed by entity and window, this works naturally. They can be diverted to a side output for separate handling, for instance written to a late-events topic and incorporated by a later batch correction. For ML features there is an additional subtlety that connects directly to Chapter 3. Whatever late-data policy the streaming pipeline applies at serving time, the training data must reflect the same policy. If the online pipeline drops events more than thirty seconds late, but the backfill computed from the warehouse includes them, the training features are systematically more complete than serving features. For a velocity feature in a fraud model, this might mean the model learns that a count of five transactions in ten minutes is unusual, when in production the same burst would appear as four because one event was late. The safest way to keep the two consistent is to log the features actually computed by the streaming pipeline and train on those logs, or to run the same streaming code over historical data in replay mode, with simulated arrival times, to produce training features. Window types and what they compute Three window types cover most feature needs. Tumbling windows are fixed-size and non-overlapping: each minute, each hour, each day. They are cheap and easy to reason about, and suit features that describe calendar periods. Their weakness is boundary sensitivity: a burst of activity that straddles two windows is split between them, and a model looking at "transactions this minute" sees two moderate values instead of one high one. Sliding windows, sometimes called hopping windows, are fixed-size and overlapping, advancing by a smaller step: a ten-minute window computed every minute. They smooth boundary effects at the cost of more computation and state, since each event belongs to several windows. Session windows group events by activity, closing after a period of inactivity. They are natural for user behaviour, where a "session" of browsing is the meaningful unit. Many ML features are better expressed not as windows emitted on a schedule but as rolling aggregates evaluated at each event: at the moment a transaction arrives, what is the count of this card's transactions in the preceding ten minutes, exactly? This is what a fraud model actually needs, and it is subtly different from the most recent completed sliding window, which might be up to a minute stale. Computing it requires keeping, per card, the timestamps of recent events and evaluating the aggregate on demand. Flink's process functions and Kafka Streams' processor API support this; some feature platforms provide it as a built-in feature type. Training data must, again, be computed with the same exact semantics, which point-in-time joins with per-event windows can provide. State, checkpoints and recovery Every aggregation over time requires state: the running counts, sums and recent events for each key. For a fraud pipeline tracking a hundred million cards, that state can be large. Stream processors keep it in local memory or on local disk, typically in an embedded RocksDB store, partitioned by key so that each processing instance holds state only for the keys of the partitions it owns. Because state is local, it must be made durable. Flink takes periodic checkpoints, consistent snapshots of all operator state plus the input offsets at which they were taken, written to durable storage, using a variant of the Chandy-Lamport distributed snapshot algorithm. On failure, the job restarts from the latest checkpoint, restores state and rewinds its inputs to the recorded offsets. Combined with transactional output to Kafka, this yields exactly-once results within the pipeline. Kafka Streams achieves a similar effect by writing every state change to a compacted changelog topic and rebuilding local state from it on recovery. Several operational consequences matter for ML pipelines. Recovery is not instantaneous. Restoring large state takes time, during which features are not being updated and lag accumulates. A fraud system that depends on fresh features needs a defined behaviour for this period, such as falling back to a model that does not use streaming features, or applying conservative default values, rather than serving silently stale values. State has to be bounded. A per-key state for every user who has ever appeared grows without limit. State time-to-live settings expire entries for keys not seen recently. These must be consistent with the feature's definition: a "transactions in the last thirty days" feature whose state expires after seven days of inactivity will report zero for a card that was active three weeks ago, which is wrong. Changing the pipeline's logic can invalidate its state. If a new version computes a feature differently, existing state may be incompatible. Flink's savepoints allow a job to be stopped, upgraded and restarted with state preserved, but only if the state schema is compatible. Otherwise the new version must rebuild state by replaying history, which requires that the input topics retain enough of it, the reason tiered storage and long retention matter. Joins in streams Features frequently combine several streams, or a stream with reference data. A transaction might need to be enriched with the merchant's category, the cardholder's home country and the most recent device fingerprint for the account. Stream processors support several kinds of join, each with its own timing semantics. A stream-table join enriches each event with the current value of a table, typically materialised from a compacted topic or a CDC stream. The value used is whatever the table held when the event was processed. In replay or backfill, "when the event was processed" is not when it originally happened, so the join can pick up a later version of the table, which is revision leakage in streaming form. Flink's temporal table joins address this by joining each event to the version of the table valid at the event's time, provided the table's history is available. A stream-stream join matches events from two streams that share a key within a time bound, such as a click and a subsequent purchase by the same user within thirty minutes. Both sides must be buffered for the duration of the bound, which can be expensive. An interval join is a stream-stream join with an explicit event-time interval, and is often the right way to build labels in real time, such as joining each recommendation impression with any click that follows within a defined window. Testing streaming pipelines Streaming code is notoriously hard to test, because its behaviour depends on the timing and order of inputs as much as on their content. A pipeline that passes every test on neatly ordered sample data can fail on the first network hiccup in production. Several techniques make streaming feature pipelines more trustworthy. Test with controlled time. The major frameworks provide test harnesses that let a test feed events with chosen event times and advance watermarks explicitly. Kafka Streams has a topology test driver; Flink provides test harnesses for operators and a mini-cluster for whole jobs. Tests should cover not just the happy path but late events just inside and just outside the allowed lateness, out-of-order events within a window, events exactly on window boundaries, duplicate events with the same ID and idle partitions. Test against the batch definition. Since the same feature is also computed in batch for training, the strongest test of a streaming implementation is to run both over the same historical events and compare the outputs. Differences should be explainable entirely by the late-data policy; anything else is a bug in one implementation or the other. Some teams run this comparison continuously in production on a sample of keys, which turns skew detection into a routine metric. Inject faults. Restart the job in the middle of processing, kill a task manager, introduce a broker failover, pause one input partition. After each, check that outputs are neither missing nor duplicated. Exactly-once claims are only as good as their behaviour under failure, and the configuration needed to achieve them, from transactional sinks to checkpoint settings to idempotent writes, is easy to get subtly wrong. Monitor the internals, not just the outputs. Useful metrics include watermark lag, the difference between wall-clock time and the current watermark; the number of late events dropped or diverted; state size per operator; checkpoint duration and failure count; and consumer lag on each input partition. A watermark that stops advancing, or state that grows steadily without levelling off, is an early warning of problems that will eventually reach the features. None of this is unique to ML. What is specific to ML is the cost of a subtle error: a velocity feature that is off by one in a small fraction of cases may never trigger an alert, and may still shift a fraud model's decisions enough to matter. The only protection is to test streaming code at least as carefully as model code, and to compare it continuously with its batch twin. Where streaming belongs Stream processing is powerful and expensive. It requires always-on infrastructure, operational expertise in state management, careful attention to time semantics and disciplined consistency with the training path. Chapter 4 suggested measuring the value of freshness before investing in it. It is worth adding that many teams find a hybrid works best: a small number of genuinely time-sensitive features computed in streams, combined with a larger set of batch features refreshed daily, served together from one online store. What a stream processor cannot do, any more than Kafka can, is decide whether the data it is processing makes sense. It will faithfully compute the rolling mean of a sensor that has started reporting in the wrong units, and write that mean to the online store within milliseconds. Speed amplifies whatever enters the pipeline, good or bad. The next chapter turns to the defences that keep bad data from reaching the model in the first place. Chapter 7: Data Quality Before the Network Everything in the preceding chapters, from careful ingestion to point-in-time joins, shared feature definitions and exactly-once streaming, ensures that data moves through the pipeline faithfully. None of it ensures that the data is right. A pipeline can preserve, with perfect fidelity and perfect timing, a column of incomes that has been divided by twelve. This chapter is about the checks that stand between data and the model, and the argument that they belong at every boundary rather than only at the end. The principle is simple. Data should have to prove itself before it moves on. At each boundary, from source to raw layer, raw to cleaned, cleaned to features and features to training set or online store, there should be explicit expectations about what valid data looks like, and data that fails them should stop, be quarantined or at minimum raise an alarm that someone is obliged to answer. The model is the last place to discover a data problem, and the worst. What can be checked It helps to separate the kinds of check, because they catch different failures and run at different costs. Table 3 lays out the main layers, roughly in order of increasing sophistication. Table 3. Layers of data validation and what each catches. Layer Example check Catches Misses Schema Column amount exists and is decimal Renames, type changes Wrong values of right type Value constraints amount between 0 and 50,000 Unit errors, sentinel values Plausible but shifted values Integrity Every order.customer_id exists Broken joins, orphans Correct joins on stale data Volume and freshness Row count within 20% of last week Missing partitions, duplicates Right count, wrong content Distribution Mean and quantiles near baseline Semantic shifts, drift Changes inside normal range Schema checks verify structure: required columns are present, types match, nested fields are where they should be. These are the cheapest checks and should be enforced everywhere, ideally by the storage layer itself, as open table formats and schema registries do. They turn renames and type changes into hard failures. Value constraints verify that individual values are plausible: non-null where required, within a range, drawn from an allowed set, matching a pattern. A temperature sensor reading of minus 999 is a sentinel for "no reading," not a temperature. An age of 212 is an error. A country code of "XX" is a default. Value constraints catch many unit errors outright, because a value twelve times too small or a hundred times too large often falls outside the plausible range. Integrity checks verify relationships: foreign keys resolve, primary keys are unique, totals reconcile with their components, a refund does not exceed its original payment. They catch broken joins, which in ML pipelines often manifest as features that are silently null for a growing fraction of entities. Volume and freshness checks verify that the right amount of data arrived on time: row counts per partition are within an expected band, the latest event timestamp is recent, no hour has zero records. Many of the most damaging pipeline failures, such as a partition never written or a day loaded twice, are caught by nothing more sophisticated than a row count compared with the same day last week. Distribution checks verify that the statistical shape of the data resembles a baseline: means, quantiles, null rates, cardinalities and category frequencies. These are the only checks that can catch semantic changes where every individual value remains plausible, and they are the bridge to drift monitoring, discussed below. Tools and how they work The tooling for data validation matured considerably in the late 2010s, led in part by large companies that had learned the cost of its absence. Google's TensorFlow Data Validation, described by Eric Breck, Neoklis Polyzotis, Sudip Roy, Steven Whang and Martin Zinkevich in "Data Validation for Machine Learning," presented at the SysML conference in 2019, computes statistics over each new batch of training or serving data, compares them with a schema that records expected types, presence, value domains and distributions, and reports anomalies. A notable design choice was to infer an initial schema from data and then have engineers review and curate it, which lowers the cost of getting started. The same group's earlier "ML Test Score" paper, presented at IEEE Big Data in 2017, proposed a rubric of tests for production readiness of ML systems, a substantial share of which concern data and features rather than models. Amazon's Deequ, described by Sebastian Schelter and colleagues in "Automating Large-Scale Data Quality Verification" in the Proceedings of the VLDB Endowment in 2018, takes a similar approach on Apache Spark, expressing checks as declarative constraints evaluated efficiently over large datasets, with support for computing metrics incrementally as data grows and for suggesting constraints from data profiles. Great Expectations, an open-source Python framework, popularised the idea of "expectations" as readable, testable assertions about data, such as an expectation that column values fall between bounds or that a column's mean lies in a range, and of generating human-readable documentation of what each dataset is expected to satisfy. Pandera offers schema and statistical checks directly on pandas and other dataframe libraries. In the SQL world, dbt's tests, and tools such as Soda, allow checks to be declared alongside transformation code and run as part of every pipeline execution. The specific tool matters less than three properties of how it is used. First, checks must run automatically on every batch or continuously on every stream, not on demand. Second, failures must have consequences: blocking a downstream step, quarantining data or paging someone. A validation report that nobody reads is decoration. Third, expectations must be versioned and reviewed alongside the code that produces the data, so that a deliberate change to the data is accompanied by a deliberate change to its expectations. Blocking versus alerting When a check fails, the pipeline has to decide what to do. This is a design decision with real trade-offs, and it should be made per check rather than globally. Blocking halts the pipeline at the failed boundary. Downstream consumers receive no new data until someone investigates. The model continues to be served with its existing features, now growing stale, and the training pipeline does not run. Blocking is right when the cost of bad data reaching the model exceeds the cost of stale data, which, for most training pipelines, it does. Retraining a model on a corrupted dataset and deploying it is far worse than retraining a day late. Quarantining separates failing records from passing ones, letting the passing data proceed and holding the failures for review. This is the dead-letter pattern from Chapter 5, applied generally. It is right when failures are at the level of individual records, such as malformed events, and the rest of the batch is trustworthy. The quarantine rate itself should be monitored, since a sudden rise usually means a systematic problem rather than scattered bad records. Alerting lets data proceed but notifies an owner. It is right for checks that are informative but noisy, such as moderate distribution shifts that may reflect real change in the world, and for early warnings where blocking would be disproportionate. A common and effective pattern is a write-audit-publish workflow. New data is written to a staging location, such as a branch or an unpublished snapshot in an open table format, audited by the full suite of checks, and only then published atomically to the location consumers read from. If the audit fails, consumers never see the bad data, and the previous good version remains in place. Table formats such as Iceberg, with branching and tagging, and tools such as lakeFS, which provides git-like branches over object storage, make this pattern straightforward. For online feature serving, where blocking means serving stale features, the fallback behaviour should be explicit. A feature pipeline that fails validation might stop updating the online store, causing features to age, and the serving system should know how old each feature is and degrade gracefully, perhaps by substituting a default or routing to a model that does not depend on the stale feature, rather than treating hours-old velocity counts as current. Data contracts Validation catches problems after they happen. Contracts aim to prevent them. A data contract is an explicit agreement between a data producer and its consumers about the structure, semantics, quality and service levels of a dataset or stream. The term gained wide currency in the early 2020s, promoted by practitioners including Chad Sanderson and Andrew Jones, whose 2023 book Driving Data Quality with Data Contracts sets out an implementation approach. A contract typically specifies the schema, with field types and meanings; semantic definitions, such as "amount is the gross transaction value in minor currency units, including tax"; quality expectations, such as null rates and value ranges; freshness and availability commitments; and an owner and change process. The crucial element is enforcement at the producer. The contract lives in the producing team's repository and their CI pipeline checks that proposed code changes do not break it, so that a developer who renames a field or changes its unit learns before deploying, not weeks later from a degraded model. Contracts address the organisational root cause identified in Chapter 1: the undeclared consumer. A contract declares the consumer, makes the producer aware that their data is an interface and gives both parties a defined process for change. It works best when producers publish purpose-built events or tables as the contracted interface, rather than exposing their internal database. CDC of internal tables can carry a contract too, but it couples the contract to the producer's storage design, which they will reasonably want to change. Contracts are not free. They require producers to accept new responsibilities, which needs management support and usually some reciprocal benefit. In practice, organisations tend to adopt them first for the handful of datasets whose breakage has caused the most pain, often those feeding revenue-critical models, and expand from there. Label quality Discussions of data quality for ML often focus on features and neglect labels, which are frequently the noisier half of the training data. Labels come from human annotators who disagree and make mistakes, from business processes with their own biases, and from proxies that only approximate the true target. The scale of the problem was illustrated by Curtis Northcutt, Anish Athalye and Jonas Mueller in "Pervasive Label Errors in Test Sets Destabilize Machine Learning Benchmarks," presented at NeurIPS in 2021. Using a technique called confident learning to flag likely errors, and then verifying them with human reviewers, they found label errors in the test sets of all ten widely used benchmark datasets they examined, including ImageNet, at rates of a few percent on average. They showed that such errors could change which model appeared best. If curated public benchmarks contain errors at this rate, internal datasets labelled under time pressure should be assumed to contain more. Several practices help. Measure inter-annotator agreement on a sample labelled by multiple people, which estimates the ceiling on achievable accuracy and reveals ambiguous categories. Write labelling guidelines with worked edge cases, and version them, since a change in guidelines is a change in the label's meaning. Use model-assisted error detection, such as confident learning or simply reviewing examples where a trained model strongly disagrees with its label, to prioritise relabelling. And for labels derived from business processes, such as "churned" or "fraudulent," document precisely how the label is computed and when it matures, as Chapter 3 discussed. Proxy labels deserve particular scrutiny. A model trained to predict clicks as a proxy for user satisfaction learns to predict clicks, including on content that is clickable but unsatisfying. A model trained on historical lending decisions as a proxy for creditworthiness learns the historical decisions, including their biases. These are not bugs that validation can catch; they are choices that a data team should make explicitly and document. The composition of the training set Quality is not only a property of individual records. A training set can consist entirely of valid, correctly labelled records and still be a poor basis for a model, because of what it contains in aggregate. Composition checks are the least developed area of data validation and among the most important. Coverage. Does the training set contain enough examples of each segment the model will serve: each country, each product line, each device type, each customer cohort? A model that will score customers in a newly launched market, using a training set drawn almost entirely from established markets, is extrapolating. Simple counts of examples per segment, compared with the expected serving mix, reveal this before training rather than after deployment. Class balance and its changes. Many ML problems, including fraud, defects and churn, have rare positive classes. A shift in the positive rate between training sets can reflect a real change, a labelling change or a pipeline error, such as a join that drops positive examples disproportionately because they have more missing fields. Tracking the label rate per segment and per time period, and alerting on sudden changes, is a cheap guard against this. Duplicates and near-duplicates. Duplicated records inflate the weight of whatever they describe, and duplicates that span the training and test sets inflate evaluation scores. Exact duplicates are found by hashing; near-duplicates, such as the same document with trivial edits or the same user activity logged twice with slightly different timestamps, need fuzzier matching. For text and image data, near-duplicate detection is a standard step; for tabular data it is often skipped and should not be. Sampling and filtering decisions. Every filter applied while building a training set, such as excluding test accounts, removing outliers or keeping only customers with complete profiles, changes what the model learns. These decisions are often made in passing, in a notebook, and never documented. They should be explicit parameters of the training set definition, recorded with each version, because a model trained on customers with complete profiles will be miscalibrated for the customers who do not have them. Composition checks bridge the gap between data quality and model quality. They ask not whether the data is correct but whether it is the right data for the job, and they deserve a place in the same automated validation suite as the schema and range checks. Drift: watching the inputs in production Validation at training time establishes a baseline. In production, the world moves away from it. Monitoring the inputs a model receives, and comparing them with what it was trained on, is how a platform notices. The basic method is to compute, over a recent window of serving traffic, the same statistics recorded for the training data, and compare. For numeric features, common measures include the population stability index, long used in credit risk modelling, which bins the values and sums a weighted log-ratio of the proportions in each bin; the Kolmogorov-Smirnov statistic, the maximum difference between the two cumulative distributions; and the Jensen-Shannon divergence or Wasserstein distance. For categorical features, changes in category frequencies and the appearance of unseen categories are the main signals. Null rates should be tracked for every feature, since a rising null rate is often the first sign of an upstream break. Thresholds are a matter of judgement and should be calibrated per feature. Credit risk practitioners have long used rules of thumb for the population stability index, treating values below roughly 0.1 as stable and above roughly 0.25 as a significant shift, but these are conventions, not laws. On large samples, statistical tests such as Kolmogorov-Smirnov will flag differences too small to matter, so effect sizes, not p-values, are the useful quantity. It is important to distinguish what kind of drift is being detected. Covariate shift is a change in the input distribution; it is directly observable. Concept drift is a change in the relationship between inputs and the target, such as fraudsters adopting new tactics so that the same feature values now mean something different; it is only observable once labels arrive, which may be weeks later. Data pipeline breakage looks like covariate shift but is caused by the pipeline, not the world. A sudden, step-shaped change in a feature's distribution on a specific date is almost always a pipeline or upstream change; a gradual trend is more often genuine drift. Distinguishing them is where lineage, described in the next chapter, earns its keep, because the first question is always what changed upstream at that time. Finally, monitoring should include training-serving skew directly. If the platform logs the features served for each prediction, it can recompute the same features through the offline path for a sample of those predictions and compare. Any systematic difference is skew. This check is cheap, decisive and much underused. Quality as a property of the system It is tempting to treat data quality as a tool to install. It is better understood as a property of the whole system, produced by many small decisions: ingestion that preserves history, schemas that are enforced, transformations that are idempotent, features that have one definition, checks at each boundary that can stop the pipeline, contracts that make producers aware of consumers, and monitoring that compares production with training. No single check catches everything. Layered together, they make it likely that when something changes, someone finds out before the model does. The remaining question is how to keep all of this understandable and reproducible as it grows, which is the subject of the final chapter. Chapter 8: Lineage, Reproducibility and the Pipeline Over Time A pipeline that is correct on the day it is built will not stay correct by itself. Sources change. Definitions are revised. Engineers leave and new ones arrive. Models are retrained, rolled back and retired. Regulators, auditors or a puzzled product manager ask why a model made a particular decision eight months ago. The machinery of the previous chapters keeps data flowing correctly in the present; this chapter is about keeping it understandable across time. Three capabilities matter most. Lineage answers where a piece of data came from and what depends on it. Reproducibility answers whether a past training set, and therefore a past model, can be recreated exactly. Ownership answers who is responsible when something goes wrong. Each sounds administrative. Each is, in practice, the difference between a data incident that takes an hour to resolve and one that takes a month. Lineage: the map of dependencies Lineage is a graph. Its nodes are datasets, such as tables, topics, files, feature views and models, and the jobs that transform them. Its edges record which job read which inputs and wrote which outputs. With column-level lineage, the edges go further and record which output columns were derived from which input columns. Lineage answers two questions that come up constantly. Looking upstream: this feature's distribution shifted on Tuesday; what feeds it, and what changed in any of those inputs around Tuesday? Looking downstream: the payments team wants to change how the amount field is computed; which features, training sets and models will be affected? Without lineage, both questions are answered by asking around, reading code and hoping. With it, they are queries. The practical challenge is collection. Lineage that is documented by hand is wrong within weeks. Lineage must be captured automatically from the systems that run the pipeline. OpenLineage, an open standard started in 2020 and now a project of the Linux Foundation's LF AI and Data foundation, defines a common format for jobs to emit lineage events, which say which run of which job read which datasets and wrote which others, along with metadata such as schemas and row counts. Integrations exist for Apache Airflow, Spark, Flink, dbt and others, and the reference backend, Marquez, along with commercial catalogues and several open-source data catalogues such as DataHub and OpenMetadata, consume those events to build the graph. For ML specifically, lineage needs to extend past the warehouse into the model lifecycle: which training set version produced which model version, and which model version is deployed where. Experiment tracking and model registry tools such as MLflow record this side. Connecting the two, so that one can trace from a deployed model back through its training set to the raw source tables, is still often a matter of disciplined conventions, such as recording dataset version identifiers as parameters of each training run, rather than an out-of-the-box feature. Reproducibility: freezing the past A model is reproducible if, given the same code, configuration and data, it can be retrained to produce the same model, or a statistically equivalent one where training is non-deterministic. Code and configuration are handled by version control. Data is the hard part, because the data a model was trained on was a query result against tables that have since changed. There are three broad approaches. Snapshot the training set. Materialise every training set as an immutable file or table, give it an identifier and record that identifier with the model. This is simple and robust. It costs storage, which is usually acceptable, and it makes the training set itself an artefact that can be inspected, validated and compared. Tools such as DVC, which tracks large data files alongside git, support this workflow. Version the sources and record the query. Instead of copying the training set, record the exact versions of the source tables, using open table format snapshot IDs or timestamps, and the code that built the training set. Re-running that code against those versions reproduces the data. This saves storage but depends on the old table versions still existing, and table formats routinely expire old snapshots to reclaim space. Retention policies must be set with reproducibility in mind, or important versions should be tagged so that they are exempt from expiry. Branch the data lake. Tools such as lakeFS and the branching features of Apache Iceberg and Project Nessie allow git-like branches and tags over whole collections of tables. A training run can tag the exact state of every input at the moment it read them. This is the most complete approach and the most infrastructure-heavy. Whichever approach is used, the principle is the same: a model's metadata must point to an exact, retrievable version of its training data. "Trained on the customer table in March" is not reproducible. "Trained on training set churn_v14, built from snapshot 4821 of customers and snapshot 1907 of events, by commit a3f9c2 of the pipeline repository" is. Reproducibility has a practical payoff beyond audit. When a newly trained model performs worse than its predecessor, the first diagnostic step is to compare the two training sets. If they cannot both be retrieved, that comparison is impossible. Backfills, migrations and other dangerous operations Some of the most consequential pipeline operations are rare ones: backfilling a new feature over two years of history, migrating from one storage system to another, changing a feature's definition, reprocessing after fixing a bug. They are rare enough that teams do them without practised procedures, and consequential enough that a mistake can corrupt every downstream dataset at once. A few rules make them safer. Write backfill output to a new location, validate it, and switch consumers over atomically, rather than overwriting in place. Compare the backfilled values with the existing live values over the period where both exist, as Chapter 3 suggested, and investigate any systematic difference before proceeding. Keep the previous version available for rollback, which open table formats make cheap. Announce the operation to downstream owners identified through lineage, so that a sudden change in their inputs is expected rather than alarming. And treat a definition change as a new feature or a new version, not an in-place edit, so that models trained on the old definition keep receiving it until they are deliberately retrained. Retention, deletion and personal data Much of the data feeding ML systems is about people, and laws such as the European Union's General Data Protection Regulation and California's privacy statutes give people rights over it, including in many cases the right to have it erased. Erasure is straightforward in an operational database, where a row is deleted. It is much harder in an ML platform, where the same person's data has been copied into raw event logs, cleaned tables, feature histories, training set snapshots and possibly the learned parameters of models. The tension with the rest of this chapter is obvious. Reproducibility argues for keeping everything immutable forever; privacy law argues for being able to remove an individual's data on request. Resolving it requires deliberate design rather than retrofitting. Several patterns help. Lineage makes erasure tractable at all, because it identifies every dataset derived from the source tables containing the person's records. Open table formats support row-level deletes, so that a person's records can be removed from historical tables without rewriting entire datasets by hand, although old snapshots containing the data must also be expired. Pseudonymisation, replacing direct identifiers with tokens at ingestion and holding the mapping in a separate, tightly controlled store, reduces how many places hold directly identifying data. A related technique, sometimes called crypto-shredding, encrypts each person's data with a per-person key and erases the key on request, rendering every copy unreadable at once. Retention policies should be set per dataset, with reasons recorded. Raw event logs might be kept for a limited period sufficient for reprocessing, while aggregated features that do not identify individuals are kept longer. Training set snapshots used for reproducibility should be included in erasure workflows, or the reproducibility guarantee should be defined to exclude erased records. Whether trained models must be retrained after erasure requests is a legal and technical question still being worked out, and research on machine unlearning is active. For most teams, the practical position is to retrain on a regular schedule from current data, so that erased records drop out of models within a bounded period, and to document that policy. The platform's job is to make that possible by knowing where every person's data lives. Orchestration and observability Batch pipelines are run by orchestrators: Apache Airflow, the most widely deployed, and newer tools such as Dagster and Prefect. Dagster in particular encourages modelling pipelines as a graph of data assets, the tables and features themselves, rather than a graph of tasks, which aligns naturally with lineage and makes it easier to ask what state each asset is in and when it was last validly updated. Whatever the orchestrator, ML pipelines benefit from treating data assets as first-class monitored objects. For each important dataset, the platform should know its freshness, its last validation result, its row count trend and its owner, and should alert when any of these goes wrong. This practice is sometimes called data observability, and a number of commercial tools offer it. The underlying idea is simple: the same rigour that site reliability engineering brought to services, with explicit service level objectives, dashboards and on-call ownership, should apply to the datasets that models depend on. A feature table that is required to be refreshed by 06:00 each day and validated against its expectations has a service level objective, whether or not anyone wrote it down. Writing it down, and monitoring it, is what makes a missed refresh an incident rather than a mystery. Pipelines for language models The rise of large language models has created a new class of data pipeline, for retrieval-augmented generation and for fine-tuning. These handle documents rather than rows, and produce embeddings and text chunks rather than numeric features. The tooling is newer and the vocabulary different, but the principles of this booklet apply almost unchanged. A retrieval pipeline ingests documents from sources such as wikis, ticketing systems, file stores and databases; parses them into text, which for PDFs and scanned documents is itself an error-prone step; splits the text into chunks; embeds each chunk with an encoder model; and writes the embeddings, with the chunk text and metadata, to a vector index. At query time, the user's question is embedded with the same encoder, the most similar chunks are retrieved and passed to the language model as context. Each stage has a counterpart in the earlier chapters. Ingestion must capture updates and, critically, deletions: a document removed from the source because it was wrong, superseded or confidential must also be removed from the index, or the system will keep retrieving it. This is the deleted-row problem of batch extraction from Chapter 2, with higher stakes. CDC-style incremental sync, keyed on stable document identifiers, is the robust solution. Chunking and embedding are feature definitions. The chunk size, overlap, parsing rules and encoder version together determine what the index contains, and changing any of them changes every embedding. Mixing chunks embedded by different encoder versions in one index degrades retrieval silently, as Chapter 4 noted for embeddings generally. The encoder version and chunking parameters should be recorded with every vector, and a change to either should trigger a controlled rebuild, ideally into a new index that is validated before traffic is switched. Quality checks apply too, adapted to the content. Parsing failures produce empty or garbled chunks, which should be detected by simple checks such as minimum length, character-set sanity and the proportion of non-text characters. Duplicate and near-duplicate documents crowd out diverse results and should be detected by hashing or embedding similarity. Access control metadata must be carried with each chunk so that retrieval respects the permissions of the original documents; a retrieval system that ignores them becomes a way to read documents one is not entitled to see. And retrieval quality should be monitored with a maintained set of test questions whose correct source documents are known, the retrieval equivalent of a validation set. Pipelines that assemble data for fine-tuning or pretraining face the same issues at larger scale, with additional emphasis on deduplication, filtering and provenance. Documenting what a training corpus contains, where each part came from and under what terms it may be used has become a practical and legal necessity, and it depends entirely on lineage captured during ingestion. Ownership and the human system All of the technical machinery described in this booklet runs inside an organisation, and its effectiveness depends on whether that organisation assigns clear responsibility. A schema registry rejects an incompatible change; someone must decide whether to negotiate the change or redesign it. A validation check blocks a pipeline at four in the morning; someone must be on call to look at it. A drift monitor flags a shift; someone must judge whether it is the world changing or a pipeline breaking. The data mesh movement, articulated by Zhamak Dehghani in a 2019 article on Martin Fowler's website and in her 2022 book Data Mesh, argues that responsibility for data should sit with the domain teams that produce it, who should treat their data as a product with consumers, quality guarantees and documentation. Whether or not an organisation adopts the full model, its central insight is directly relevant to ML: the producers of data must know that their data feeds models and must accept some responsibility for its fitness for that purpose. Data contracts, discussed in Chapter 7, are the technical expression of this; ownership metadata in catalogues and lineage graphs is the organisational one. Within ML teams, the cultural point made by the Sambasivan study bears repeating. Data work needs to be recognised and rewarded as real engineering, not treated as preparation for the interesting part. Teams that measure themselves only on model metrics will systematically underinvest in the pipelines that determine whether those metrics mean anything in production. Teams that track data incidents, measure time to detection and treat a prevented data cascade as an achievement build platforms that keep working. Keeping it proportionate It is possible to read a chapter like this and conclude that every ML project needs a feature store, a streaming platform, a lineage system, a data catalogue, contracts with every producer and a full observability suite. It does not. The machinery should scale with the stakes and the number of models. A single batch model producing weekly forecasts needs a reproducible training set, solid point-in-time logic, a handful of validation checks that can block the pipeline and an owner. That is a few days of work, and it prevents most of the failures this booklet describes. What should not scale down is the underlying discipline: respect for time, one definition per feature, checks at boundaries that can stop the pipeline, and the ability to say exactly what data a model learned from. Those are cheap at small scale and become steadily more expensive to retrofit as a platform grows. Conclusion The argument of this booklet has been that a machine learning system is bounded by the pipeline that feeds it, and that the most damaging pipeline failures are silent ones. Having followed data from its sources through ingestion, time alignment, feature computation, streaming and validation to the operation of the whole over time, it is worth drawing out what follows from that argument, because it implies a different way of organising ML work from the one most teams start with. The model is downstream of everything Most ML teams are organised around models. Projects are defined by the model they produce; success is measured by the model's metrics; the most senior engineers work on architecture and training. Data preparation is the first phase of a project, done once, and the pipeline that produced the training set is often a notebook that nobody runs again. The preceding chapters suggest that this inverts the actual dependency structure. A model is a function of its training data and is evaluated on data from the same pipeline. Its production behaviour is a function of the serving data. Every guarantee about the model's quality is conditional on guarantees about the data: that features in training were computed as they would have been at prediction time, that serving features are computed identically, that the inputs have not drifted beyond what the model learned, that the labels mean what everyone thinks they mean. If those conditions fail, the model's metrics describe a system that does not exist. The practical implication is that the pipeline is the product, and the model is one of its outputs. A team that can retrain a model from a reproducible, validated, point-in-time correct training set at the press of a button, and knows within hours when serving inputs depart from training inputs, can iterate on models quickly and safely. A team that has a superb model and a fragile pipeline has a liability. Where the effort should go If one were to allocate effort by expected damage avoided, the priorities that emerge from this booklet are roughly as follows. First, get time right. Point-in-time correctness in training sets prevents leakage, which is the most common reason models disappoint in production, and it costs little once the habit is established: build training sets from spines and as-of joins, use availability time rather than event time, define label maturity windows, and split evaluation data by time. No other single practice yields as much. Second, define each feature once. Whether through a feature store or a shared library, ensure that the logic which computes a feature for training is the logic that computes it for serving. Log served features and compare them with offline recomputations. Training-serving skew is invisible without this check and common with it. Third, validate at boundaries and give validation teeth. Schema enforcement, value constraints, volume checks and distribution checks at each stage, with a deliberate choice for each about whether failure blocks, quarantines or alerts. A blocked pipeline is an inconvenience. A model retrained on corrupted data is an incident. Fourth, preserve history. Ingest changes, not just current state; keep raw data immutable; retain enough of the event log to rebuild features after a definition changes. Information discarded at ingestion cannot be recovered by any amount of later work. Fifth, make ownership explicit. Every dataset feeding a model needs a producer who knows it feeds a model, and a consumer who knows whom to call. Contracts, lineage and catalogues are the tools; the substance is a relationship. Streaming infrastructure, sophisticated drift detection and full lineage platforms come after these, scaled to need. They are valuable, but they amplify the foundations rather than substituting for them. A Kafka-based real-time feature pipeline built on leaky definitions delivers leaky features faster. What remains unsettled Several questions in this field do not yet have settled answers, and a reader building pipelines now should hold views on them lightly. The boundary between feature stores, vector databases and lakehouse platforms is moving. Large data platform vendors have been absorbing feature store capabilities, as the Databricks acquisition of Tecton illustrates, while vector search is becoming a standard capability of general-purpose databases. It is not clear whether a distinct feature store category will survive or dissolve into broader platforms. The design principles will outlast the category either way. Streaming is becoming cheaper and more accessible, through managed services, tiered storage and SQL-based streaming databases, which weakens the cost argument for keeping features in batch. Yet the correctness challenges of streaming, around watermarks, late data and consistency with training, have not become easier. Lower infrastructure cost may tempt teams into streaming features whose freshness does not justify their complexity. Data contracts are widely discussed and unevenly adopted. They depend on producer teams accepting responsibility for downstream uses, which is an organisational change rather than a tooling one, and it is not yet clear how far the practice will spread beyond organisations that have suffered enough data incidents to demand it. And pipelines for language models are young. Practices for versioning document corpora, keeping retrieval indexes consistent with source permissions, evaluating retrieval quality continuously and documenting the provenance of fine-tuning data are still forming. The principles of this booklet apply to them, but the tooling and conventions are still being worked out. What to do differently For a reader responsible for a machine learning system in production, a few concrete actions follow directly. Find out how each model's training set is built, and check it for temporal leakage by asking, for every feature, when its value would actually have been available. If the answer is not known, that is the first problem. Pick the model that matters most and compare its served features with offline recomputations for a sample of recent predictions. If they differ, there is skew; if there is no way to make the comparison, start logging served features. List the upstream sources of that model's data and their owners. Ask each owner whether they know their data feeds a model. Where they do not, have the conversation, and consider whether a contract, or at least a notification process, is warranted. Add a small number of validation checks at the boundary where data enters the training pipeline: schema, row counts, null rates and ranges for the most important features. Make at least one of them blocking. Make sure the next model trained can be reproduced, by recording the exact version of every dataset it used. None of these steps requires new infrastructure. Each takes days, not months. Together they address the failures that, in the experience of practitioners and in the research literature, account for most of the gap between machine learning that works in evaluation and machine learning that works in the world. The work is unglamorous, and it is where the reliability of an AI system is actually decided. Further Reading Books Martin Kleppmann, Designing Data-Intensive Applications (O'Reilly, 2017).** The best single treatment of the foundations underneath every pipeline in this booklet: replication, partitioning, transactions, logs, batch and stream processing. Its chapters on stream processing and on derived data are essential background for Chapters 2, 5 and 6. A second edition, co-written with Chris Riccomini, updates the material. Joe Reis and Matt Housley, Fundamentals of Data Engineering (O'Reilly, 2022).** A clear map of the data engineering lifecycle, from generation and ingestion to storage, transformation and serving, written for practitioners and managers alike. Strong on the trade-offs between architectural choices. Chip Huyen, Designing Machine Learning Systems (O'Reilly, 2022).** Written from the ML side, with unusually good chapters on training data, feature engineering, data distribution shifts and monitoring. A natural companion to the data engineering view taken here. Tyler Akidau, Slava Chernyak and Reuven Lax, Streaming Systems (O'Reilly, 2018).** The authoritative explanation of event time, watermarks, triggers and windowing, by engineers behind Google's Dataflow and Apache Beam. Demanding but definitive for anyone building streaming features. Jay Kreps, I Heart Logs (O'Reilly, 2014).** A short book expanding Kreps's essay on the log as a unifying abstraction for data systems. The clearest statement of why Kafka is designed the way it is. Gwen Shapira, Todd Palino, Rajini Sivaram and Krit Petty, Kafka: The Definitive Guide, 2nd edition (O'Reilly, 2021). A practical reference on Kafka's internals, configuration and reliability guarantees. Predates the removal of ZooKeeper but remains sound on partitioning, delivery semantics and operations. Zhamak Dehghani, Data Mesh (O'Reilly, 2022).** The full argument for domain-owned data treated as a product. Useful for anyone thinking about the organisational side of data ownership discussed in Chapter 8. Andrew Jones, Driving Data Quality with Data Contracts (Packt, 2023).** A practitioner's guide to designing and implementing data contracts, including the organisational changes they require. Papers and essays D. Sculley and colleagues, "Hidden Technical Debt in Machine Learning Systems," Advances in Neural Information Processing Systems (2015).** The classic account of why the machinery around ML models is where complexity and risk accumulate. Nithya Sambasivan and colleagues, "'Everyone wants to do the model work, not the data work': Data Cascades in High-Stakes AI," Proceedings of the CHI Conference on Human Factors in Computing Systems (2021).** Interview-based evidence of how data problems compound and surface late, and of the cultural undervaluation of data work. Eric Breck, Shanqing Cai, Eric Nielsen, Michael Salib and D. Sculley, "The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction," IEEE International Conference on Big Data (2017).** A practical checklist of tests for production ML systems, many concerning data and features. Eric Breck, Neoklis Polyzotis, Sudip Roy, Steven Euijong Whang and Martin Zinkevich, "Data Validation for Machine Learning," Proceedings of SysML (2019).** The design of Google's data validation system, the basis of TensorFlow Data Validation. Sebastian Schelter and colleagues, "Automating Large-Scale Data Quality Verification," Proceedings of the VLDB Endowment (2018).** The design of Amazon's Deequ library for declarative data quality checks at scale. Curtis G. Northcutt, Anish Athalye and Jonas Mueller, "Pervasive Label Errors in Test Sets Destabilize Machine Learning Benchmarks," NeurIPS Datasets and Benchmarks Track (2021).** Evidence that label errors are common even in canonical benchmarks, and a method for finding them. Tyler Akidau and colleagues, "The Dataflow Model," Proceedings of the VLDB Endowment (2015).** The paper that formalised the separation of event time and processing time and introduced the windowing and triggering model used by modern stream processors. Jay Kreps, "The Log: What every software engineer should know about real-time data's unifying abstraction," LinkedIn Engineering blog (2013). The essay that explains the idea behind Kafka, and still the best short introduction to log-centric data architecture. Martin Zinkevich, "Rules of Machine Learning: Best Practices for ML Engineering," Google. A widely read set of practical rules, including extensive advice on training-serving skew and feature logging. Hashtags: #DataEngineeringForAI #DataEngineering #ArtificialIntelligence #MachineLearning #MachineLearningPipelines #DataPipelines #RobustDataPipelines #MLOps #DataOps #ProductionMachineLearning #MLInfrastructure #DataInfrastructure #DataArchitecture #DataReliability #DataQuality #DataValidation #DataContracts #SchemaValidation #SchemaEvolution #SchemaRegistry #DataIngestion #BatchProcessing #StreamProcessing #RealTimeDataProcessing #EventDrivenArchitecture #ChangeDataCapture #CDC #Debezium #ApacheKafka #KafkaStreams #ApacheFlink #EventStreaming #DistributedStreaming #DataStreaming #StreamingAnalytics #EventTimeProcessing #Watermarks #LateArrivingData #ExactlyOnceProcessing #IdempotentProcessing #TransactionalOutbox #DataConsistency #DataIntegrity #DataLakehouse #DataLakes #ApacheIceberg #DeltaLake #ApacheHudi #ApacheParquet #DataVersioning #DataLineage #DataObservability #DataMonitoring #DataDriftDetection #DistributionShift #TrainingServingSkew #DataLeakage #TemporalDataLeakage #PointInTimeCorrectness #PointInTimeJoins #FeatureEngineering #FeatureStores #Feast #OfflineFeatureStore #OnlineFeatureStore #FeatureMaterialization #FeatureFreshness #HistoricalDataReconstruction #BitemporalData #DataBackfills #ReproducibleMachineLearning #MLDataTesting #StatisticalValidation #ModelDataMonitoring #DataCascades #DataPipelineAutomation #DataPlatformEngineering #MachineLearningOperations #LLMDataPipelines #Embeddings #VectorDatabases #RetrievalAugmentedGeneration #RAG #DataGovernance #ReliableAI

Download the Book (PDF): Introduction In 1984, two Cambridge undergraduates named David Braben and Ian Bell shipped a space trading game called Elite on the BBC Micro. The machine had 32 kilobytes of memory, part of which was taken by the screen. The game contained eight galaxies of 256 star systems each, every one with a name, a position, an economy, a government type, a population, and a short descriptive sentence. None of that was stored. What the disk held was a handful of numbers and a small routine that scrambled them in a fixed, repeatable way. Ask the routine for system 7 of galaxy 2 and it would perform the same arithmetic it always performed and produce the same planet it always produced. The universe existed only as a function. Four decades later, the same idea sits underneath some of the largest and most commercially important games ever made. Minecraft produces worlds tens of millions of blocks across from a single 64-bit seed. No Man's Sky claims 18,446,744,073,709,551,616 planets, a number that is not a marketing flourish but simply two raised to the sixty-fourth power: the count of distinct seeds its generator accepts. Spelunky builds a fresh, fair, completable cave every time the player dies, which is often. Townscaper lets someone click on an empty sea and watch a coherent harbour town, with arches, stairways, and rooftop gardens, assemble itself around the click. Each of these is a different algorithm. Each depends on the same underlying contract. This booklet is about that contract and the algorithms that fulfil it. It is written for developers who can program and want to understand, at the level of the actual mathematics and code, how content can be generated rather than authored: terrain from noise functions, caves from cellular automata, plants from rewriting grammars, and towns from constraint solvers. It assumes no prior background in procedural generation, computer graphics, or formal language theory. It does assume the reader is comfortable reading short code and thinking in terms of grids, arrays, and loops. The argument of this booklet The common picture of procedural generation is that it means "random content". That picture is wrong in a way that leads developers to build bad generators. Randomness on its own produces static. A grid of tiles chosen by coin flips is not a level; a heightmap filled with independent random numbers is not a landscape. Every generator that produces something worth looking at works by taking a small amount of randomness and pushing it through a large amount of structure. The structure is where the design lives. Put more sharply: a procedural generator is a deterministic function from a seed to content, and its quality is decided almost entirely by the constraints it imposes, not by the randomness it consumes. Perlin noise is valuable because it constrains random values to vary smoothly. Cellular automata are valuable because they constrain each cell to agree with its neighbours. L-systems constrain growth to follow a grammar. Wave function collapse constrains every tile to fit the tiles around it. The algorithms differ in where they put the constraint, at what scale, and how expensive it is to satisfy. Choosing between them, and more often layering them, is a matter of matching the kind of constraint to the kind of structure the content needs. The practical consequence runs through every chapter. When a generator produces ugly, repetitive, or broken output, the fix is almost never "more randomness" or "a better random number generator". It is a better-shaped constraint: a frequency that matches the scale of the feature, a neighbourhood rule that encodes the right local agreement, a grammar that captures the branching habit of the plant, an adjacency table that forbids the impossible join. The developers who build good generators are the ones who think of themselves as designing constraint systems, not as harnessing chance. What the chapters cover The chapters move from foundations to individual algorithm families and then to the problem of judging whether a generator is any good. Chapter 1 sets out the contract. It covers seeds, pseudo-random number generators, and the shift from sequential random streams to hash-based, position-addressable randomness that makes infinite and chunked worlds possible. It explains why Minecraft players can share a seed and see the same mountain, and why a generator that consumes random numbers in the wrong order quietly breaks that promise. Chapter 2 builds Perlin noise from first principles: why value noise looks blocky, how Ken Perlin's 1985 gradient formulation fixed it, what his 2002 revision changed and why, and where simplex noise and its relatives fit. Chapter 3 turns noise into terrain. Single noise layers make poor landscapes; real terrain generators sum octaves, remap values through hand-shaped curves, warp the input domain, and combine several independent noise fields to decide not just height but climate and biome. The chapter follows how Minecraft rebuilt its terrain generator in version 1.18 around these ideas and how No Man's Sky approached planet-scale surfaces. Chapter 4 covers cellular automata for caves: the simple "4-5 rule" that turns random fill into organic caverns, the published research on running it on infinite maps, the connectivity problems it creates, and the post-processing every shipped version needs. Chapter 5 steps back from pure algorithms to designed randomness. Spelunky is the case study: a generator that guarantees a solvable path by building its structure first and filling it with hand-authored fragments second. This is the template for most commercially successful level generators, and it clarifies when the elegant algorithms in the other chapters are the wrong tool. Chapter 6 introduces L-systems, the parallel rewriting grammars Aristid Lindenmayer devised in 1968 to model cell growth and that Przemyslaw Prusinkiewicz later turned into a complete system for modelling plants. The chapter covers turtle interpretation, branching, stochastic and parametric rules, and how to keep the output from looking like a textbook diagram. Chapter 7 widens the view from a single plant to vegetation across a world: space colonization for tree crowns, Poisson disk sampling for natural-looking scatter, and rule-based placement driven by the same noise fields that shape terrain. Chapter 8 explains wave function collapse, the constraint-propagation algorithm Maxim Gumin published in 2016. It separates the overlapping model from the tiled model, walks through observation, entropy, and propagation, and connects the algorithm to the older constraint-satisfaction and model-synthesis research that it rediscovered. Chapter 9 takes wave function collapse to the scale of cities: solving in chunks, handling contradictions without restarting the world, making generation infinite, and the design choices behind Oskar Stålberg's Bad North and Townscaper, where the grid itself is irregular. Chapter 10 addresses the question that every generator eventually raises: is this output any good, and how would we know? It covers expressive range analysis, automated playability testing, search-based generation, performance budgets, and the persistent problem that a generator can produce a billion distinct outputs that all feel the same. The conclusion draws out what follows from treating generation as constraint design, where the field remains genuinely unsettled, and what developers starting a generator today should do differently from what the folklore suggests. A note on sources and code The algorithms here are well documented, and the booklet leans on primary sources wherever possible: Perlin's two papers, Lindenmayer's original article and The Algorithmic Beauty of Plants, Gumin's repository and the research that analysed it, conference talks by the developers of the games discussed, and the academic textbook Procedural Content Generation in Games by Noor Shaker, Julian Togelius, and Mark J. Nelson. Where a commercial game's internals are discussed, the description relies on what its developers have said publicly or on what its community has documented from the shipped code, and the text says so. Code snippets are short and written in a neutral, Python-like style so that they translate easily into C#, C++, GDScript, or Rust. They are meant to show the shape of each algorithm, not to be production implementations. A production noise function needs attention to floating-point precision, vectorization, and seam handling that would obscure the teaching point; a production wave function collapse solver needs bit-packed domains and careful memory layout. The chapters point out where those concerns arise. One more convention. The word "random" appears constantly in this subject, and it is almost always shorthand for "pseudo-random and seeded". Nothing in a game generator is random in the sense of being unpredictable to the machine. Everything is determined by the seed. That determinism is not a limitation to work around; it is the property that makes the whole enterprise work, and Chapter 1 begins there. Chapter 1: Seeds, Determinism, and the Generator Contract Every procedural generator makes a promise, whether its author states it or not: given the same inputs, it will produce the same output. A player who types a seed into Minecraft and posts it online expects strangers to find the same village by the same river. A server that streams terrain to clients expects each client to agree about where the ground is. A designer who finds a bug on level 37 of a roguelike expects to be able to reproduce level 37. All of these depend on determinism, and determinism is easy to break by accident. This chapter covers the machinery that keeps the promise: seeds, pseudo-random number generators, and the more important idea of hash-based randomness, which lets a generator ask "what is the random value at this location?" rather than "what is the next random value?". That shift is what makes infinite, chunked, and parallel worlds possible. What a seed actually is A seed is a number that fully determines a generator's output. In the simplest designs, it initializes the internal state of a pseudo-random number generator (PRNG), a deterministic algorithm that produces a sequence of numbers which pass statistical tests for randomness while being entirely reproducible. The classic example is the linear congruential generator, which updates a state value by multiplying, adding, and taking a remainder. Java's standard java.util.Random is one: it keeps 48 bits of state and on each step computes the new state as the old state times the constant 0x5DEECE66D, plus 11, modulo 2 to the 48th. Early versions of Minecraft were written in Java and leaned on this class throughout world generation. A consequence that the game's seed-finding community has exploited for years is that although Minecraft seeds are 64-bit values, any part of the generator driven only through java.util.Random depends on just the lower 48 bits, because that is all the state the class can hold. Seeds that share those bits produce identical results for those features. This is not a flaw players notice while playing, but it illustrates the first lesson: the effective size of your seed space is the size of the smallest state any part of your pipeline passes through. Seeds also need to come from somewhere. Most games accept a text string from the player and hash it into a number, and generate a seed from the clock or an operating-system entropy source when the player provides nothing. Hashing a string seed matters because it lets "glacier" and "Glacier" be different worlds without asking players to type integers. The trouble with sequential randomness A PRNG produces a stream. Each call returns the next number. That model works well for a small, bounded generator: seed the PRNG, generate a dungeon level by calling it a few thousand times in a fixed order, done. The level is reproducible because the order of calls is fixed. The stream model starts to fail as soon as any of four things happen. First, the world becomes too large to generate all at once. If terrain is produced on demand as the player walks, in chunks, then the order in which chunks are generated depends on where the player walks. If chunk generation draws from a single shared stream, two players who walk different routes from the same seed get different worlds. Second, the generator becomes parallel. If four threads generate four chunks at once and share a stream, the interleaving of their calls depends on thread scheduling, which is not deterministic. Third, the code changes. Suppose a developer adds one extra random call early in the pipeline, perhaps to decide whether a tree has a bird's nest. Every random number after that call shifts by one position in the stream. Every feature downstream changes. A seed that players have been sharing for a year now produces a different world. This is one of the most common ways shipped games break their own seeds between versions, and it happens even to experienced teams. Fourth, the generator needs to answer questions out of order. A minimap might need to know which biome lies a thousand blocks away without generating everything in between. All four problems have the same root: the random value assigned to a feature depends on how many random values were consumed before it. The fix is to make the random value depend only on what the feature is and where it is. Hash-based randomness The alternative is to treat randomness as a function of coordinates. Instead of asking a stream for its next number, the generator computes a hash of the seed and the position: def rand_at(seed, x, y, channel): h = seed h = mix(h ^ (x * 0x9E3779B1)) h = mix(h ^ (y * 0x85EBCA77)) h = mix(h ^ (channel * 0xC2B2AE3D)) return h & 0xFFFFFFFF # 32 random bits def mix(h): h ^= h >> 16; h *= 0x7FEB352D h ^= h >> 15; h *= 0x846CA68B h ^= h >> 16 return h & 0xFFFFFFFF The mix function here is a bit-mixing finalizer of the kind used in hash tables: a sequence of shifts, exclusive-ors, and multiplications by odd constants that spreads every input bit across every output bit. The channel argument separates independent uses at the same location: channel 0 might decide terrain height, channel 1 whether a tree grows, channel 2 the tree's species. Because each use has its own channel, adding a new feature does not disturb existing ones. Because the value depends only on seed, position, and channel, it is identical no matter which chunk asks first, which thread computes it, or what else has been generated. The game programmer Squirrel Eiserloh made this case at GDC in 2017 in a talk on what he called noise-based random number generation, arguing that most game code should use a positional hash rather than a stateful generator for exactly these reasons. His Squirrel3 function is a few lines of multiplication and bit shifting that takes a position and a seed and returns 32 bits. The idea is older than the talk, and graphics programmers have used hash-based randomness inside shaders for decades because GPUs have no convenient way to share a sequential stream across thousands of parallel threads. But the talk crystallised it for game developers. The standard pattern in a large generator combines both approaches. A hash of the seed and the chunk coordinates produces a per-chunk seed. That per-chunk seed initializes a small, fast PRNG which is then used sequentially within the chunk, where order is fixed and controlled. Features that cross chunk boundaries, such as rivers, roads, or large structures, use positional hashes at a coarser grid so that both neighbouring chunks agree about them. Table 1 compares the generators most often found in game code and the role each typically plays. Table 1. Common sources of pseudo-randomness in game generators. Generator State Access pattern Typical role Linear congruential (e.g. java.util.Random) 48 or 64 bits Sequential Legacy code; weak low bits Mersenne Twister (1998) 624 32-bit words Sequential General use; heavy to reseed often xorshift family (Marsaglia, 2003) 64-128 bits Sequential Fast per-chunk streams PCG family (O'Neill, 2014) 64-128 bits Sequential, seekable Per-chunk streams, good statistics SplitMix64 / hash finalizers None (stateless) Positional Per-cell values, deriving sub-seeds The Mersenne Twister is worth a specific warning. It is the default in several languages' standard libraries and has excellent statistical properties over long runs, but its state is about 2.5 kilobytes and seeding it is comparatively slow. A generator that creates a fresh Mersenne Twister for every chunk, or worse every cell, spends more time seeding than generating. Small generators such as the xorshift and PCG families, or a stateless hash, are better fits for the "reseed constantly" pattern that chunked worlds demand. Determinism beyond the random numbers Getting the random numbers right is necessary but not sufficient. Several other sources of nondeterminism sneak into generators. Floating-point arithmetic. The same floating-point expression can produce slightly different results on different compilers, optimisation settings, or processor architectures, particularly when fused multiply-add instructions or extended-precision intermediates are involved. A noise function evaluated on a PC and on a console may disagree in the last bit. Usually that does not matter, because the difference is invisible. It matters a great deal when a threshold decides something discrete. If a cave is carved wherever noise exceeds 0.5, a value of 0.49999999 on one machine and 0.50000001 on another means one player has a wall where another has a tunnel. Multiplayer games that generate terrain independently on each client either use integer or fixed-point arithmetic in the decision-making parts of the generator, or have a single authority generate the world and send it to everyone. Iteration order of containers. Hash maps and sets in many languages iterate in an order that depends on memory addresses or on a per-process random salt. Python randomises string hashing between runs by default; several other runtimes do something similar for security. A generator that loops over a set of candidate locations and places a village at the first suitable one will place it differently on different runs. Sort before iterating whenever the order affects the output. Time and frame rate. Any generator that does work "per frame" or uses wall-clock time to budget its work must ensure the budget affects only when results arrive, not what they are. Version drift. Changing generator code changes the output. Games handle this in different ways. Minecraft has repeatedly changed its generator between major versions, and worlds keep the terrain already generated while new chunks use the new algorithm, which is why long-lived worlds sometimes show abrupt seams where old terrain meets new. Other games version their generators explicitly, storing a generator version number alongside the seed and keeping the old code paths available. If seeds are a social feature of the game, as they are for speedrunning and seed-sharing communities, treat generator changes as breaking changes and plan for them. Deriving seeds hierarchically Large generators need many independent random sources: one per stage, one per chunk, one per structure, sometimes one per object. The clean way to provide them is to derive every sub-seed from its parent with a hash, forming a tree. The world seed hashes with the stage name to give a stage seed; the stage seed hashes with chunk coordinates to give a chunk seed; the chunk seed hashes with an object index to give an object seed. Hashing string labels such as "caves" or "villages" rather than numeric constants makes the tree readable in code and makes collisions between unrelated uses unlikely. The tree has a useful property for debugging and design. Any node can be regenerated in isolation from its seed, without generating its siblings. A designer who wants to see a hundred variants of a village can hold everything else constant and vary only the village seed. A tester who finds a malformed tree can log its object seed and reproduce it in a unit test. Tools that let designers browse generated content usually expose exactly this hierarchy. Infinite, but not quite "Infinite world" is a convenient phrase that never means literally infinite. Hash-based generation removes the need to store the world, but the coordinates themselves are numbers with limited precision, and that limit eventually shows. Minecraft's Java Edition provides the most famous example. Before Beta 1.8 in 2011, the terrain generator fed block coordinates into its noise functions in a way that overflowed at around 12,550,821 blocks from the origin. Beyond that point the terrain degenerated into a bizarre region of stacked, swiss-cheese walls that the community named the Far Lands. A player named Kurt J. Mac famously began walking toward them in 2011 as a long-running video series. The bug was an integer overflow in the noise inputs, not a deliberate edge. Later versions removed the Far Lands and placed a world border at 30 million blocks, which is a practical admission that floating-point precision in physics and rendering becomes a problem long before any generator runs out of hash outputs. Two techniques push the limit back. The first is to keep coordinates as integers for as long as possible, converting to floating point only after subtracting a local origin, so that noise functions always receive small numbers. The second is to wrap noise inputs: most noise functions are periodic at some large scale anyway, because their permutation tables repeat, and choosing that period deliberately avoids surprises. Generator design as a pipeline With the determinism contract in place, it is worth stating the architecture that nearly every serious generator converges on, because the rest of the booklet fits into it. A generator is a pipeline of stages, each of which is a pure function of the seed and of the outputs of earlier stages. A typical open-world pipeline runs roughly as follows: large-scale climate and continental shape; elevation; erosion or other terrain refinement; water bodies; biome assignment; caves and underground features; large structures such as villages; vegetation and small decorations; and finally gameplay entities. Each stage reads only from its own random channel and from the stages before it. This structure has three advantages. It keeps determinism local, because each stage can be tested in isolation with a fixed seed. It makes it possible to evaluate stages at different resolutions, so that climate is computed on a coarse grid and decorations on a fine one. And it gives designers clear places to intervene. If villages keep appearing on cliff edges, the fix belongs in the village placement stage, which can read the elevation stage's output and reject steep sites. The alternative, a monolithic generator that interleaves all decisions, is how many first attempts look, and it is how most first attempts become unmaintainable. Every algorithm in the following chapters slots into one or more stages of this pipeline: noise into climate and elevation, cellular automata into caves, L-systems into vegetation, constraint solvers into structures and towns. A minimal working example To make the contract concrete, here is the skeleton of a chunked heightmap generator that satisfies it. It uses a positional hash to derive each chunk's seed, generates heights from a function of absolute world coordinates (so chunk edges match), and never touches shared state. CHUNK = 32 def chunk_seed(world_seed, cx, cz): return rand_at(world_seed, cx, cz, channel=0xC0FFEE) def generate_chunk(world_seed, cx, cz): heights = [[0] * CHUNK for _ in range(CHUNK)] for lz in range(CHUNK): for lx in range(CHUNK): wx, wz = cx CHUNK + lx, cz CHUNK + lz heights[lz][lx] = terrain_height(world_seed, wx, wz) rng = PCG32(chunk_seed(world_seed, cx, cz)) trees = place_trees(rng, heights) # order fixed within chunk return heights, trees Two details carry the weight. Heights are computed from world coordinates, not local ones, so the height at the shared edge of two chunks is the same whichever chunk computes it. And the per-chunk PRNG is used only for decisions that live entirely inside the chunk; a tree that could overhang a chunk boundary would need either a positional decision at a coarser scale or a rule that trees are placed only away from edges. The function terrain_height is where the interesting mathematics begins. Filling it with rand_at directly would produce a field of independent spikes, a landscape that looks like television static extruded into three dimensions. What it needs is randomness that varies smoothly, with a controllable scale, so that nearby points have similar heights and distant points are unrelated. That is the problem Ken Perlin solved in the early 1980s, and it is the subject of the next chapter. Chapter 2: Noise, From Random Values to Perlin's Gradients In the early 1980s Ken Perlin was working at Mathematical Applications Group, Inc., one of the companies that produced computer-generated imagery for Disney's Tron (1982). He was frustrated by how machine-like computer graphics looked. Surfaces were too clean, edges too sharp, and textures, where they existed, were scanned images that repeated visibly. What he wanted was a primitive that a programmer could use to add controlled irregularity to anything: marble, fire, clouds, wood grain, the subtle unevenness of a real surface. The result, published at SIGGRAPH in 1985 in a paper titled "An Image Synthesizer", was a function he called noise. In 1997 the Academy of Motion Picture Arts and Sciences gave Perlin a Technical Achievement Award for it. In games, it became the default way to make a landscape. This chapter builds noise from the ground up, because the reasons behind each design decision explain how to use it well and how to recognise when it is going wrong. What a noise function must do The requirements are easy to state. A noise function takes a point in space, in one, two, three, or more dimensions, and returns a number. It must be: • Deterministic: the same point always returns the same value, so it obeys the contract from Chapter 1. • Continuous and smooth: nearby points return nearby values, with no jumps or visible creases. • Band-limited: its variation happens at roughly one characteristic scale. Zoomed far out it looks like static; zoomed far in it looks like a gentle slope; at its natural scale it looks like rolling hills. • Statistically uniform: no direction or location looks special. There should be no visible grid, no preferred orientation, no repeating pattern within any distance the player will notice. • Cheap: a terrain generator may evaluate it millions of times per second. Independent random values per point fail the second and third requirements. The obvious fix is to place random values on a grid and interpolate between them. That fix is called value noise, and its shortcomings are what led to Perlin's approach. Value noise and its grid problem Value noise assigns a pseudo-random number to every integer lattice point, using a positional hash, and interpolates for points in between. In one dimension, the value at x = 3.4 is a blend of the values at 3 and 4, weighted toward 3. The choice of interpolation matters. Linear interpolation produces a continuous result, but its slope jumps at every lattice point, which shows up as visible creases. A smoothing function fixes that by easing in and out of each lattice point. The classic choice is the cubic 3t² − 2t³, often called smoothstep, which has zero slope at t = 0 and t = 1. Blending with smoothstep gives a curve with no creases. In two and more dimensions, value noise interpolates in each axis in turn. The result is smooth, but it has a persistent visual defect: its features line up with the grid. Peaks and troughs can only sit at lattice points, because those are the only places where the function takes its random values, and everything between is a blend. The eye picks out the underlying square lattice, particularly in a heightmap viewed from above, where ridges tend to run horizontally and vertically. Value noise also has a lot of its energy at low frequencies relative to its nominal scale, which makes it look blurry and blobby. Perlin's gradient noise Perlin's key move was to store something other than a value at each lattice point. He stored a gradient: a random direction vector. The noise function is defined to be exactly zero at every lattice point, and the gradient at that point determines which way the function slopes as it leaves. To evaluate noise at an arbitrary point in two dimensions: 1. Find the grid cell containing the point, which is bounded by four lattice corners. 2. For each corner, look up its pseudo-random gradient vector. 3. For each corner, compute the offset vector from that corner to the point. 4. Take the dot product of each corner's gradient with its offset vector. This gives four values, each describing how high the function would be at the point if that corner's slope extended across the whole cell. 5. Blend the four values using a smooth fade curve on the fractional coordinates. In code, the two-dimensional version is short: def perlin2(x, y): xi, yi = floor(x), floor(y) xf, yf = x - xi, y - yi u, v = fade(xf), fade(yf) n00 = dot(grad(xi, yi), xf, yf) n10 = dot(grad(xi+1, yi), xf - 1, yf) n01 = dot(grad(xi, yi+1), xf, yf - 1) n11 = dot(grad(xi+1, yi+1), xf - 1, yf - 1) return lerp(lerp(n00, n10, u), lerp(n01, n11, u), v) def fade(t): return t t t (t (t * 6 - 15) + 10) # 6t^5 - 15t^4 + 10t^3 Because the function is pinned to zero at every lattice point, peaks and troughs fall between lattice points, at positions that depend on how the gradients happen to align. That breaks up the grid alignment that plagues value noise. Gradient noise also concentrates its energy in a narrower band of frequencies, so a single layer looks crisper and more evenly sized. The output is mostly in a symmetric range around zero, with values near the extremes much rarer than values near the middle, a distribution that matters when a later stage applies thresholds. How the gradients are chosen Perlin's original implementation did not hash coordinates with a modern mixing function. It used a permutation table: an array of the integers 0 to 255 shuffled into a fixed random order, then duplicated to length 512 so that indexing never needs a bounds check. The gradient index for lattice point (x, y, z) is found by chained lookups: p[p[p[x] + y] + z], with each coordinate masked to its low eight bits. The table makes the function periodic with period 256 in every axis, which is far enough that repetition is rarely noticed in a texture but can become visible across a large game world if the noise is sampled at a low frequency. The permutation table is also where the seed goes. Shuffling the 256 entries with a seeded PRNG gives a different but equally valid noise function for every seed. Perlin's 2002 revisions In 2002, Perlin published a short paper, "Improving Noise", that fixed two defects in the 1985 version. Both are instructive. The fade curve. The original used the cubic smoothstep 3t² − 2t³. That curve has zero first derivative at the cell edges but a non-zero second derivative, which means the curvature of the noise jumps at every cell boundary. For a colour texture this is invisible. For anything that uses the noise's derivatives, it is not. Bump mapping and displacement compute surface normals from the slope of the noise, and lighting depends on how normals change, so a discontinuity in curvature shows up as faint grid-aligned lines in the shading. The fix was the quintic 6t⁵ − 15t⁴ + 10t³, which has zero first and second derivatives at both ends. This is the fade function in the code above, and it is the version almost every implementation now uses. The gradients. The original chose gradients as random unit vectors from a precomputed table. Random directions occasionally cluster, which produces patches where neighbouring gradients point the same way and the noise forms long, uncharacteristic streaks. The revision replaced them, in three dimensions, with a fixed set of twelve directions pointing from the centre of a cube to the midpoints of its twelve edges, vectors such as (1, 1, 0) and (0, −1, 1). Because each component is −1, 0, or 1, the dot product needs no multiplication at all, only additions and sign flips, which is faster. The set is padded to sixteen entries by repeating four of them so that the gradient can be selected with a four-bit mask of the hash. The fixed set is evenly distributed, so no direction is over-represented. These are small changes, but they show the general pattern of noise design: every visible artifact traces back to a specific mathematical property, and the fix is to change that property, not to add more randomness on top. Simplex noise and the cost of dimensions Classic Perlin noise has a cost problem in higher dimensions. A point in n-dimensional space lies in a hypercube with 2ⁿ corners, and the function must compute a gradient dot product at each one and blend them all. In two dimensions that is four corners, in three it is eight, in four it is sixteen. Four-dimensional noise is useful in practice, for example to animate a three-dimensional cloud field by moving through the fourth dimension over time, or to produce seamlessly tiling two-dimensional noise by mapping the plane onto a torus in four-dimensional space. In 2001 Perlin introduced simplex noise to address this. Instead of dividing space into squares and cubes, it divides it into simplices: triangles in two dimensions, tetrahedra in three. A simplex in n dimensions has only n + 1 corners, so the work grows linearly rather than exponentially. Instead of interpolating, each corner contributes a radially symmetric falloff kernel multiplied by its gradient dot product, and the contributions are summed. The result has fewer directional artifacts than classic Perlin noise, because the triangular lattice is less obviously aligned with the axes, and it has a well-defined analytic derivative that is cheap to compute. Simplex noise was harder to understand from Perlin's original description, which was written with hardware implementation in mind. Stefan Gustavson's 2005 tutorial, "Simplex noise demystified", gave the explanation and reference code that most game implementations derive from. For many years simplex noise also had a legal complication. Perlin's employer patented an implementation of it in the United States, and the patent covered its use for texture synthesis in three or more dimensions. That uncertainty led Kurt Spencer to publish OpenSimplex in 2014, a different simplex-style construction designed to avoid the patent, and a later variant, OpenSimplex2. The patent expired in early 2022, so the legal reason to avoid simplex noise is gone, but OpenSimplex variants remain common in engines and libraries because they were adopted while the patent was in force and because some developers prefer their visual character. Worley noise and other bases Not every useful noise is gradient noise. In 1996 Steven Worley described what he called a cellular texture basis function, now usually called Worley noise or cellular noise. It scatters feature points through space, one or a few per grid cell, positioned by a hash, and returns for each sample point the distance to the nearest feature point. The output looks like a field of cells, similar to a Voronoi diagram, with bright edges and dark centres or the reverse. Using the distance to the second-nearest point, or the difference between the first and second distances, produces cracked mud, scales, cobblestones, and crystal patterns. In terrain generation, Worley noise is useful for plateaus, mesas, crater fields, and for dividing a world into regions such as biomes or territories with natural-looking borders. Table 2 summarises the main noise bases. Table 2. Common noise bases and their characteristics. Noise Lattice Main artifact Relative cost Typical game use Value noise Square/cubic Grid-aligned blobs Lowest Cheap coarse masks Perlin (1985) Square/cubic Curvature creases, streaks Moderate Legacy terrain, textures Perlin (2002) Square/cubic Mild axis alignment Moderate Default terrain heightmaps Simplex / OpenSimplex Triangular/tetrahedral Few; subtle in some variants Lower in 3D+ 3D density, 4D animation Worley (1996) Scattered points Visible cell structure Higher Regions, rock, craters Derivatives and tiling Two further properties of gradient noise are worth knowing before using it for terrain, because later techniques depend on them. Analytic derivatives. Because Perlin and simplex noise are built from polynomials and dot products, their partial derivatives can be computed exactly in the same pass as the value, at modest extra cost. The derivative of the quintic fade is 30t⁴ − 60t³ + 30t², and the chain rule handles the rest. Having the gradient of the noise available directly is useful in several ways. Surface normals for lighting come straight from it, with no need to sample neighbouring points. The slope of terrain, which drives vegetation placement and erosion-like effects in the next chapters, is available everywhere for free. And, as Chapter 3 shows, feeding the accumulated derivative back into the octave sum is one of the cheapest ways to make noise terrain look eroded. Inigo Quilez's articles on noise derivatives are the most widely used practical reference for this. Seamless tiling. Textures, skyboxes, and some small game worlds need noise that wraps: the left edge must match the right and the top the bottom. Classic Perlin noise can be made to tile at a chosen integer period by wrapping lattice coordinates modulo that period before hashing, so that the lattice points on opposite edges share gradients. An alternative that works for any noise is to map the two-dimensional plane onto a torus embedded in four dimensions, sampling four-dimensional noise at the point (cos u, sin u, cos v, sin v) scaled appropriately. The torus has no edges, so the result tiles perfectly in both directions, at the cost of evaluating higher-dimensional noise. This is one of the main practical uses of four-dimensional simplex noise. Frequency and amplitude A single noise function has a natural feature size of about one lattice cell. To control the scale, multiply the input coordinates by a frequency before evaluating, and multiply the output by an amplitude: height = amplitude perlin2(x frequency, z * frequency) With a frequency of 0.01, one lattice cell spans 100 world units, so hills are around 100 units across. The amplitude sets how tall they are. Most beginner mistakes with noise are frequency mistakes: sampling at integer coordinates with a frequency of 1, which returns zero at every point because the function is pinned to zero on the lattice; or using a frequency so high that the result is indistinguishable from static. There is a subtler point. A heightmap made from one layer of Perlin noise at any frequency looks artificial: smooth, rounded hills of roughly uniform size, with nothing large and nothing small. Real terrain has detail at every scale, from continents to pebbles. The standard response is to sum many layers of noise at increasing frequencies and decreasing amplitudes, a technique called fractional Brownian motion, and then to reshape the result. That is the subject of the next chapter. Noise in three dimensions: density instead of height One more distinction matters before moving on. A heightmap stores one height per (x, z) column, so it cannot represent overhangs, arches, or caves: every column has exactly one surface. Three-dimensional noise lets a generator define a density at every point in space instead. Where density is positive the point is solid, where it is negative it is air, and the surface is wherever density crosses zero. The simplest density function combines a vertical gradient with noise: def density(x, y, z): return (base_height - y) + 20 perlin3(x 0.02, y 0.02, z 0.02) The first term is positive below base_height and negative above it, which produces a flat ground plane. The noise term pushes the surface up and down and, because it varies in y as well, can produce floating chunks and overhangs. Turning a density field into a renderable mesh requires an isosurface extraction algorithm such as marching cubes, or, in a block-based game like Minecraft, simply filling every block whose centre has positive density. Minecraft has used three-dimensional density noise for its terrain since its early development, which is why it has always had overhangs and floating islands, and its 1.18 terrain overhaul is built entirely around carefully shaped density functions. The next chapter takes those shaping techniques apart. Chapter 3: Shaping Terrain with Octaves, Curves, and Warps A single layer of Perlin noise produces a landscape that nobody would mistake for a real one. The hills are all the same size, rounded, evenly spaced, and featureless at close range. Real landforms have structure across many scales at once: a continent has mountain ranges, a range has peaks, a peak has ridges, a ridge has boulders. They also have shapes that noise does not produce on its own: flat plains next to sudden cliffs, sharp ridgelines, river valleys that run downhill for hundreds of kilometres, and beaches that sit at a consistent height above the sea. Turning noise into terrain is a matter of imposing those structures. This chapter covers the main techniques in roughly the order a terrain pipeline applies them: summing octaves, reshaping the distribution, warping the input, combining multiple fields, and simulating erosion. It then follows two shipped systems, Minecraft's 1.18 terrain and No Man's Sky's planets, to show how the techniques combine in practice. Octaves and fractional Brownian motion The first step is to add detail at many scales. Evaluate noise several times, each time doubling (roughly) the frequency and halving (roughly) the amplitude, and sum the results. Each layer is called an octave, by analogy with music, where an octave doubles the frequency of a note. def fbm(x, z, octaves=6, lacunarity=2.0, gain=0.5): total, amp, freq, norm = 0.0, 1.0, 1.0, 0.0 for i in range(octaves): total += amp noise(x freq, z * freq) norm += amp amp *= gain freq *= lacunarity return total / norm This sum is called fractional Brownian motion, or fBm, after the mathematical process it approximates. Two parameters control its character. Lacunarity is the frequency multiplier between octaves; gain, sometimes called persistence, is the amplitude multiplier. With a gain of 0.5, each octave contributes half as much height as the one before, so the large shapes dominate and the fine octaves add texture. With a gain closer to 1, small details become as tall as large ones and the terrain becomes rough and chaotic. With a lower gain, the result is smooth and gently undulating. Two practical details are easy to miss. First, using exactly 2.0 for lacunarity means every octave's lattice lines up with the lattice of the octave before it at every second point, which can reinforce grid artifacts. Many implementations use something like 1.98 or 2.03 instead, or rotate each octave's input by a fixed angle. Second, each octave should be decorrelated from the others, either by giving each its own seed or by adding a large offset to the coordinates, otherwise all octaves share a zero at the origin and the terrain develops a suspicious point of symmetry there. The number of octaves is limited by the smallest feature worth generating. If terrain is sampled once per metre, octaves whose features are smaller than a metre add only aliasing. A heightmap whose first octave has features 2,000 metres across needs about eleven octaves to reach one-metre detail at a lacunarity of 2. Variations on the sum fBm treats every octave the same way. Small changes to the per-octave operation produce distinctly different landforms, and these variants, most of them catalogued by F. Kenton Musgrave in the book Texturing and Modeling: A Procedural Approach, are the basic vocabulary of procedural terrain. Billow noise takes the absolute value of each octave before summing. The fold at zero produces sharp creases at the bottom and rounded tops, which looks like piled clouds or rolling, lumpy hills. Ridged noise inverts that: it takes one minus the absolute value, so the sharp creases point upward and become ridgelines. Squaring the result sharpens the ridges further. Ridged noise is the standard starting point for mountain ranges. Ridged multifractal noise, Musgrave's refinement, scales each octave's contribution by the value of the previous octave. Where the large-scale signal is high, on ridges, fine detail is strong; where it is low, in valleys, fine detail is suppressed. The result has jagged peaks and smooth valley floors, which is closer to real eroded mountains than plain fBm, because in reality sediment fills valleys and smooths them while peaks stay rough. The multifractal idea generalises: any time detail should depend on location, let the amplitude of the fine octaves depend on the value of the coarse ones or on a separate control field. Reshaping the distribution fBm produces values that cluster around the middle of their range. Mapped directly to height, that gives a world that is mostly mid-elevation, with mountains and deep water both rare and both equally rounded. Real landscapes are lopsided. Large areas are flat lowland, coastlines sit at a consistent level, and mountains rise steeply out of plains. The fix is to pass the noise value through a remapping function before using it as height. The simplest is a power curve: raising a value in the zero-to-one range to a power greater than 1 flattens the low ground and steepens the high ground, producing broad plains and isolated peaks. Terracing, rounding height to a set of levels with smooth transitions, produces mesas and stepped hillsides. The most flexible approach is a hand-drawn curve, usually a piecewise spline, that maps input noise to output height. A designer can then make the lowest 30 percent of the noise range into ocean floor, give the coast a gentle shelf, add a long, flat plain, and finish with a steep rise into mountains, all by moving control points. This is less mathematically elegant than tuning octave parameters, but it gives artists direct control over the elevation profile, which is what they usually want. As the Minecraft case below shows, the idea scales up to splines that take several noise fields as input. Domain warping The features of fBm are isotropic: they have no preferred direction and no flow. Real terrain is full of directional structure. Ridges curve, valleys meander, rock strata fold. Domain warping produces that structure by distorting the input coordinates with another noise field before evaluating the main one: def warped(x, z): qx = fbm(x + 0.0, z + 0.0) qz = fbm(x + 5.2, z + 1.3) return fbm(x + 4.0 qx, z + 4.0 qz) The first two calls produce a smooth vector field; the third samples the main noise at displaced positions. Because the displacement varies smoothly, nearby points stay nearby and the result remains continuous, but straight features become curved, and the whole field takes on a swirled, flowing look. Applying the warp twice, warping the warp, produces the marbled, folded patterns that Inigo Quilez popularised in his widely cited article on the technique. The offsets such as 5.2 and 1.3 are arbitrary; they exist only to make the two warp components independent. In terrain, a modest warp breaks up the blobby look of plain fBm and makes ridges and coastlines wander convincingly. A strong warp creates alien landscapes. The warp amplitude, the 4.0 in the code, is one of the most effective single parameters for moving a generator away from "obviously Perlin". Combining fields: climate, continents, and biomes A heightmap alone does not make a world. A useful generator also decides what each region is like: desert, forest, tundra, swamp. The standard approach, used in some form by most open-world generators, is to compute several independent low-frequency noise fields, interpret each as a climate variable, and choose a biome from the combination. The two most common variables are temperature and humidity, a scheme that resembles the Whittaker biome diagram used in ecology, where biomes are arranged on a chart by annual temperature and precipitation. Hot and dry gives desert; hot and wet gives rainforest; cold and dry gives tundra. Because the fields are smooth noise, biomes form large contiguous regions and transition gradually. The subtlety is that climate and terrain should influence each other. Mountains should be cold. Coasts should be wetter than inland plateaus. Generators handle this by feeding elevation into temperature (subtracting a lapse rate with altitude), or, more powerfully, by making the climate fields inputs to the terrain shape rather than outputs from it. Erosion The techniques so far shape terrain statistically. None of them produces what water does: river networks that drain consistently downhill, valleys that widen as they descend, alluvial fans at the base of mountains, talus slopes below cliffs. These features arise from a physical process that runs over geological time, and the only reliable way to get them is to simulate something like that process. Hydraulic erosion simulations come in two broad families. Grid-based methods, going back to work by Musgrave, Kolb, and Mace published in 1989, store water and sediment amounts in each heightmap cell and repeatedly move water downhill, letting it pick up sediment where it flows fast and deposit it where it slows. Particle-based methods drop thousands or millions of virtual raindrops at random positions, let each roll downhill while carrying and depositing sediment, and accumulate the changes. Both produce strikingly realistic results. Thermal erosion, a simpler process, moves material from any slope steeper than a talus angle to its lower neighbour, which softens cliffs into scree slopes. Erosion has a major drawback for games: it is a global, iterative process. The height of a cell after erosion depends on water that flowed from far uphill. That violates the locality that chunked generation relies on. Run erosion on a chunk in isolation and its edges will not match its neighbours. Shipped games deal with this in three ways. They run erosion offline on a finite map, which works for games with bounded worlds. They run it on a coarse global grid in advance and use the result as an input to finer local generation. Or they approximate its look with local tricks: ridged multifractals for valley smoothing, and derivative-based techniques that suppress detail on steep slopes, which mimic the visual effect of erosion without its global dependency. Case study: Minecraft 1.18 Minecraft's terrain generator was substantially rebuilt for version 1.18, the second half of the Caves and Cliffs update, released on 30 November 2021. The rebuild extended the world's vertical range to run from y = −64 to y = 320 and replaced the earlier approach, in which biomes were chosen first and each biome nudged terrain height, with a system in which several noise fields jointly determine both terrain shape and biome. The new system, documented in detail by the community on the Minecraft Wiki and exposed to modders through data packs, rests on six parameters, summarised in Table 3. Table 3. Noise parameters in Minecraft's 1.18 world generation (as documented on the Minecraft Wiki). Parameter Main role Effect at high values Continentalness Distance inland from ocean Inland, higher terrain Erosion Flat versus mountainous Flatter, lower terrain Weirdness (and derived peaks and valleys) Local peaks and river valleys; biome variants Selects variant biomes; drives peaks/valleys Temperature Climate Warmer biomes Humidity (vegetation) Climate Wetter, denser vegetation Depth Vertical position relative to surface Underground biomes The first three parameters drive terrain shape through splines. A spline, in this context, is a piecewise curve whose control points can themselves be other splines, so the output height offset is a nested function of continentalness, erosion, and the peaks-and-valleys value. At low continentalness the curve produces ocean floor; as continentalness rises it climbs through a coastal shelf to inland terrain; erosion then decides whether that inland terrain is flat plain or dramatic mountains; and peaks and valleys add local highs and river channels. Additional splines compute a "factor" that controls how strongly three-dimensional noise can deform the surface, which is how the game produces overhangs in some places and smooth slopes in others, and a "jaggedness" term that adds sharp peaks to mountain tops. Biome selection then treats the six parameter values at a location as a point in six-dimensional space and picks the biome whose defined region of that space is nearest. Because the same fields drive both terrain and biome, mountains and mountain biomes coincide, rivers sit in valleys, and beaches appear at the coast, without any explicit coordination code. The case is instructive because every element is a technique already covered. The fields are octave-summed noise. The terrain profile is a remapping curve, made multidimensional. The density field is three-dimensional noise shaped by those curves. The innovation is not any single algorithm but the decision to make a small number of smooth fields the shared source of truth from which everything else derives, and to give designers splines rather than octave parameters as their main control. Case study: No Man's Sky No Man's Sky (Hello Games, 2016) faces a harder version of the problem: whole planets, seamless from orbit to the ground, generated on the fly on consumer hardware. Its planets use a voxel density representation, so caves, overhangs, and arches are possible, and their surfaces are generated in chunks as the player approaches. Sean Murray, the studio's founder, described the terrain approach at GDC in 2017 in a talk on building worlds with mathematics. The core of it was a single, heavily parameterised noise function, internally nicknamed "uber noise", which combines many of the techniques above in one evaluation: octave summation, domain warping, ridging, and, notably, the use of the noise's own analytic derivatives to vary detail. Where the accumulated slope is steep, finer octaves are damped, which mimics the effect of erosion smoothing steep ground into valleys without running a global simulation. Different planets get different parameter sets, which is how one function produces both gentle grassy worlds and jagged alien ones. In a separate GDC 2017 talk, the studio's Innes McKendrick covered the engineering of continuous world generation, including how voxel data is generated and meshed in chunks around the player at increasing levels of detail. The game's launch also became a cautionary tale about procedural variety, which Chapter 10 returns to. Players quickly noticed that eighteen quintillion planets drew on a recognisable set of building blocks. Later free updates reworked terrain and planet types repeatedly, including a major overhaul of planetary generation in the 2024 update Worlds Part I. The arithmetic of the seed space was never the limit; the limit was how many genuinely different structures the generator could express. Putting a terrain stage together A modern terrain stage for a chunked world typically combines these techniques like this: 1. Evaluate a few low-frequency fields per location: continentalness, a mountain mask, temperature, humidity. Use domain warping on the continental field so coastlines wander. 2. Map those fields through spline curves to a base height and a roughness factor. 3. Add detail with fBm or ridged noise, scaled by the roughness factor, and with fine octaves damped on steep slopes. 4. If the world needs overhangs or caves, treat the result as the zero-crossing of a three-dimensional density field and add 3D noise scaled by another factor. 5. Choose the biome from the field values, so terrain and biome agree by construction. Every step is local, which preserves chunk independence. What the stage cannot do on its own is carve the networks of tunnels and caverns that players expect underground. Three-dimensional noise can produce caves, and Minecraft now uses noise for much of its cave system, but there is an older, simpler, and very different technique that produces caves with a distinctly organic character from almost nothing: cellular automata. Chapter 4: Cellular Automata for Caves Noise functions are continuous by nature. They produce smooth gradients, and to get a discrete structure like a cave, with walls and open floor, a generator has to threshold them, declaring everything above some value solid. The results can be good, but they tend to look like what they are: contour lines of a smooth field. Real caves, formed by water dissolving limestone along fractures, have a different character, with lumpy chambers, irregular pillars, and passages that pinch and widen. A cellular automaton produces that look from a random starting grid and a single local rule, and it is one of the cheapest, most reliable techniques in procedural generation. What a cellular automaton is A cellular automaton is a grid of cells, each in one of a small number of states, updated in discrete steps. At each step every cell computes its next state from its own current state and the states of its neighbours, according to a fixed rule, and all cells update simultaneously. The concept goes back to work by John von Neumann and Stanislaw Ulam in the 1940s on self-reproducing machines. The best-known example is John Conway's Game of Life, introduced to a wide audience by Martin Gardner's "Mathematical Games" column in Scientific American in October 1970, in which a cell is born if it has exactly three live neighbours and survives if it has two or three. Life is famous for producing complex, unpredictable behaviour from a simple rule. Cave generation wants the opposite: a rule that rapidly settles into stable, smooth-edged blobs. The rule that does this is a kind of local majority vote. The 4-5 rule Start with a grid where each cell is randomly set to wall or floor, with a wall probability of around 45 percent. The result looks like static. Then apply the following rule several times. For each cell, count the walls among its eight surrounding neighbours, the Moore neighbourhood: • A wall cell stays a wall if four or more of its neighbours are walls; otherwise it becomes floor. • A floor cell becomes a wall if five or more of its neighbours are walls; otherwise it stays floor. This is usually called the 4-5 rule. It was popularised among roguelike developers by an article on the RogueBasin wiki describing a cellular automata method for generating cave-like levels. It can be stated more compactly: a cell becomes a wall if the number of walls in its full three-by-three block, including itself, is at least five. That is simply a majority vote of nine cells. def step(grid, w, h): out = [[0] * w for _ in range(h)] for y in range(h): for x in range(w): walls = 0 for dy in (-1, 0, 1): for dx in (-1, 0, 1): nx, ny = x + dx, y + dy if nx < 0 or ny < 0 or nx >= w or ny >= h: walls += 1 # treat outside as wall else: walls += grid[ny][nx] out[y][x] = 1 if walls >= 5 else 0 return out After one step, isolated wall cells in open areas disappear and isolated floor cells in solid areas fill in. After two or three steps, the static has resolved into blobby regions with smooth edges. After four or five steps the grid is essentially stable; further iterations change very little. Treating out-of-bounds cells as walls ensures the cave is sealed at the map edge. Why does this work? A majority rule smooths. A cell surrounded mostly by walls becomes a wall; a cell surrounded mostly by floor becomes floor. Small features, which by definition have few cells of their own type nearby, are erased. Large regions grow slightly rounder each step as their corners, which have fewer same-type neighbours, are trimmed. The process is a discrete analogue of blurring an image and then thresholding it, and like blur-and-threshold it converges to shapes whose boundaries have low curvature. The parameters that matter Three numbers control the output. Initial wall density. At 45 percent, the result is a network of connected chambers and passages. Below about 40 percent, walls erode away and the result is mostly open space with scattered pillars. Above about 50 percent, floor regions shrink into isolated pockets. The output is quite sensitive to this value around the 45 to 50 percent range, because it sits near a percolation threshold, the density at which open regions stop connecting to each other. Threshold. Raising the birth threshold from five to six makes walls harder to create, so caves become more open. Lowering it makes them more closed. Changing the survival threshold independently gives further control over how jagged edges remain. Iterations. Fewer iterations leave rougher, more noisy edges; more iterations produce smoother, rounder chambers. Beyond five or so the effect is negligible. A useful refinement from the same RogueBasin article handles a common failure: large open areas with nothing in them. During the first few iterations, add a second condition: a cell also becomes a wall if there are very few walls (for example, two or fewer) within a radius of two cells. This seeds pillars in the middle of big caverns. After those first few iterations, switch back to the plain rule to smooth everything. Mixing rules across iterations this way is a general technique; early steps can shape the large-scale structure and later steps clean up the edges. The connectivity problem The 4-5 rule makes no promise that the floor is connected. Typical output contains one or two large cave systems and a scattering of small, sealed pockets. For a game, sealed pockets are at best wasted space and at worst a place where a key item or the exit spawns out of reach. Every shipped use of cellular automata caves includes a post-processing step to deal with this. The first part is always the same: identify the connected regions with a flood fill. def regions(grid, w, h): label = [[-1] * w for _ in range(h)] result = [] for y in range(h): for x in range(w): if grid[y][x] == 0 and label[y][x] < 0: cells, stack = [], [(x, y)] label[y][x] = len(result) while stack: cx, cy = stack.pop() cells.append((cx, cy)) for nx, ny in ((cx+1,cy),(cx-1,cy),(cx,cy+1),(cx,cy-1)): if 0 <= nx < w and 0 <= ny < h and grid[ny][nx] == 0 and label[ny][nx] < 0: label[ny][nx] = len(result) stack.append((nx, ny)) result.append(cells) return result The flood fill uses four-way connectivity, considering only orthogonal neighbours. That matters: if the player can move only orthogonally, two floor cells touching at a corner are not connected, even though they look connected. The connectivity used in analysis must match the connectivity the player experiences. With regions identified, there are three standard strategies: 1. Keep the largest region and fill the rest. This is the simplest and is often enough. It wastes some generated space but guarantees a single connected cave. If the largest region is too small, say under 40 percent of the map, discard the whole map and regenerate with a new seed. This generate-and-test loop is a core pattern, and Chapter 10 returns to it. 2. Connect regions with tunnels. For each small region, find the nearest cell in the main region and carve a passage between them, either a straight line, an L-shaped corridor, or a randomised "drunkard's walk" that wanders toward the target. Carved tunnels can be smoothed by running one more automaton step afterwards, which blends them into the organic style of the rest of the cave. 3. Ensure connectivity by construction. Before running the automaton, carve a guaranteed path, for example a random walk from entrance to exit, into the initial grid and protect it from being filled. The automaton then shapes the cave around a path that already exists. The third option illustrates a theme that recurs throughout the booklet: global properties such as "the exit is reachable" are hard to guarantee with local rules alone, so generators typically lay down the global structure first and let local rules decorate it. Placing things in the cave A connected cave is still only a shape. A game needs entrances, exits, treasures, monsters, and features that make the space playable. Two cheap analyses make placement much better than uniform random scattering. Distance fields. A breadth-first search from the entrance gives every floor cell its walking distance from the start. The exit can be placed at or near the farthest point, guaranteeing that the player has to traverse the cave. Treasure can be placed in dead ends with high distance values; enemies can be spaced along the distance gradient so difficulty rises with progress. Wall counts. Counting walls in a larger neighbourhood around each floor cell distinguishes open chambers from narrow passages and alcoves. Alcoves, cells with many surrounding walls, are natural places for chests. Large open areas suit set-piece encounters. Narrow passages are chokepoints where a designer might place a door or a trap. Both analyses reuse the data the automaton already produced and cost almost nothing to compute. They also show why procedural generation tends to work best as a pipeline of simple stages: the cave shape and the gameplay placement are separate problems with separate solutions. Infinite caves The 4-5 rule as stated works on a bounded grid. Making it work in a chunked, infinite world runs into the locality problem from Chapter 1: a cell's state after several iterations depends on cells several steps away, so a chunk generated in isolation will have edges that disagree with its neighbours. In 2010, Lawrence Johnson, Georgios Yannakakis, and Julian Togelius published a short paper titled "Cellular automata for real-time generation of infinite cave levels" at the Procedural Content Generation in Games workshop. They used the majority-rule automaton with a Moore neighbourhood, an initial rock proportion, a fixed number of iterations, and a neighbour threshold as the parameters, and focused on generating an endless cave map piece by piece fast enough to run during play. Their approach to the boundary problem was to generate each new section with knowledge of its neighbours, so that the automaton saw consistent data across the seam, and to ensure connectivity between sections explicitly. They also reported that the generation of a section was fast enough on ordinary hardware to keep ahead of a moving player. The general principle is useful well beyond caves. After k iterations, a cell's state depends on cells within k steps of it. So to generate a chunk's interior correctly, start from an initial random grid that extends k cells past the chunk on every side, generated with positional hashing so that neighbouring chunks agree on the shared margin, run the automaton on the enlarged grid, and keep only the interior. Each chunk does a little redundant work in its margin, but its final edges match its neighbours exactly. The margin grows with the number of iterations, which is another reason to keep iteration counts low. A complete cave stage Assembled into a pipeline stage, a robust cave generator for a bounded roguelike level runs as follows. Derive a level seed from the run seed and the depth. Fill the grid with walls at the chosen density, carving a protected random-walk path from the entrance to a provisional exit area so that a route exists. Apply two iterations of the pillar-seeding variant of the rule, then three of the plain 4-5 rule. Label regions with a flood fill, keep the region containing the entrance, and either connect or fill the rest. Check the resulting floor fraction against a minimum and maximum; if it falls outside, derive a new seed from the old one and retry, up to a fixed limit, after which fall back to a simpler, guaranteed layout. Compute a distance field from the entrance, place the exit near its maximum, and place treasure and encounters using distance and wall counts. Every step is cheap. On a grid of a hundred by a hundred cells, the automaton iterations, flood fill, and distance field together cost a few hundred thousand simple operations, far below a frame's budget on any current hardware. The retry limit and the fallback layout are not optional: without them, an unlucky seed can, in principle, loop forever, and the fallback ensures that the worst case is a less interesting level rather than a hang. Variations The basic two-state, two-dimensional automaton extends naturally. Three dimensions. The same majority rule in a 26-cell neighbourhood produces three-dimensional cave systems in voxel worlds. The density parameter needs retuning, because percolation thresholds are different in three dimensions, and the results tend to need more aggressive connectivity repair. More states. An automaton can have water, lava, or different rock types as additional states, each with its own rules. A simple example is to run the cave automaton, then run a second automaton on the floor cells that grows patches of moss or puddles according to a different threshold. Each layer stays simple. Smoothing other generators. The 4-5 rule is an excellent post-process for any binary map. Threshold a noise field to get a rough cave, then run two automaton steps to remove single-cell noise and soften the contour-line look. Combine a hand-carved room layout with automaton-shaped edges to make rooms look like natural caverns. Roguelike developers have long used cellular automata as a component in this way: Brian Walker's Brogue, for example, generates cave-like areas as automaton-smoothed blobs that are then fitted into a larger dungeon structure. Rendering. Grid output looks blocky. For a smooth visual boundary, run marching squares over the grid, which produces line segments along the boundary between wall and floor cells, or treat the wall count as a density value and extract a smooth contour. Noise caves and carvers: the alternatives It is worth comparing cellular automata with the other main cave techniques, because the choice depends on the game. Carvers trace paths through solid rock and remove material along them. Minecraft used this approach for most of its history: starting points were chosen by hash, and from each a tunnel wandered through the world as a sequence of spheres or ellipsoids, steered by a pseudo-random walk. This is sometimes called the "Perlin worm" technique when the worm's direction is driven by noise. Carvers produce long, connected tunnel networks, but they are hard to make chunk-local, because a worm that starts in one chunk can cross many others. Minecraft handled that by having each chunk consider worms starting in a range of nearby chunks and carving only the parts that fall within itself. Noise caves threshold three-dimensional noise. Minecraft's 1.18 update added noise caves in three named styles: large "cheese" caves where low-frequency noise falls below a threshold, producing big caverns with pillars; long "spaghetti" caves produced where two noise fields are both near zero, which traces thin, winding tunnels along the intersection of their zero surfaces; and narrower "noodle" caves made the same way at smaller scale. Noise caves are perfectly chunk-local and need no iteration, but they have no inherent notion of connectivity. Cellular automata produce the most organic chamber shapes and are cheap on bounded maps, but need margins to work in chunked worlds and need connectivity repair. For a two-dimensional roguelike or a single cave level, cellular automata are usually the best choice: they produce good-looking results in a few dozen lines of code. For a large voxel world, noise caves or carvers integrate more cleanly with the terrain pipeline. Many games use more than one. The point is not that any one technique is correct but that each encodes a different constraint: carvers constrain caves to follow paths; noise constrains them to follow smooth fields; automata constrain each cell to agree with its neighbours. All three, though, share one weakness. They produce space, not design. A cellular automaton has no idea that a level needs a beginning, a middle, and an end, or that the player must be able to reach the exit. The previous section showed how to retrofit those guarantees with flood fills and tunnels. The next chapter looks at a generator that started from the guarantee and built everything else around it. Chapter 5: Designed Randomness and the Spelunky Model The algorithms in the previous chapters are elegant. A few lines of noise or a single automaton rule produce endless terrain or caves. But if you list the procedurally generated games that are most admired specifically for their level design, the roguelikes and roguelites that players replay hundreds of times, you find that most of them do not rely primarily on those algorithms. They use something less mathematically pure and more effective: hand-authored fragments assembled according to a structure that guarantees playability. The canonical example is Spelunky, Derek Yu's platformer, first released as freeware in 2008, remade in high definition in 2012, and followed by Spelunky 2 in 2020. Its generator is small enough to explain completely in a few pages, and it encodes a lesson that applies to every other technique in this booklet: put the guarantees in the structure, and put the variety in the details. The problem Spelunky had to solve A roguelike platformer is unforgiving to its generator. In a top-down dungeon crawler, a level is playable if every room is reachable on foot, which a flood fill can check. In a platformer, reachability depends on gravity, jump height, ladders, and drops. A ledge three tiles higher than the player can jump is a wall. A pit with no way out is a trap the player can never escape. And Spelunky players die constantly and immediately start a new level, so the generator runs thousands of times per player. A small rate of broken levels would be noticed very quickly. At the same time, the levels need to feel designed. They need interesting shapes, interesting combinations of hazards, secrets, and a mixture of open and tight spaces. Pure noise or cellular automata cannot give that sense of authorship. The generator, step by step The structure of Spelunky's generator has been described by Yu himself, in his 2016 book about the game for Boss Fight Books, and was analysed in detail from the original source code by Darius Kazemi in an interactive essay, "Spelunky Generator Lessons". The description here follows those sources. Step one: a grid of rooms Each main level is a four-by-four grid of rooms, and each room is ten tiles wide and eight tiles tall, giving a level of forty by thirty-two tiles. The room is the unit of structure. Everything inside a room is decided later. Step two: the solution path Before any tile is placed, the generator builds a path through the grid from top to bottom. It picks a random room in the top row as the start. It then repeatedly chooses a direction: left, right, or down, with left and right more likely than down. Moving left or right marks the next room as part of the path. Hitting the edge of the grid forces a move down. Moving down from a room marks that room as needing an exit at the bottom, and the room below as needing an entrance at the top. When the path moves down out of the bottom row, the room it left becomes the exit. As the path is built, each room on it is assigned a type according to which openings it needs: • Type 0: not on the path. No openings are guaranteed. • Type 1: on the path, open to the left and right. • Type 2: on the path, open left, right, and at the bottom, because the path drops out of it. • Type 3: on the path, open left, right, and at the top, because the path arrives from above. That is the entire guarantee. Because every room on the path is open on the sides the path passes through, and the path connects the entrance to the exit, the level is always completable. No search, test, or repair is needed. Playability is a property of the structure, established before any detail exists. Step three: room templates Each room type has a set of hand-designed templates, written as ten-by-eight grids of characters. A template for a type 2 room, for example, has an open passage on its left and right edges and a gap in its floor. Templates use a small vocabulary of symbols: definite solid ground, definite empty space, ladders, and, importantly, probabilistic tiles. One symbol means "solid ground with some probability"; another means "place a randomly chosen obstacle chunk here", where the chunk is a small block of tiles chosen from its own set of hand-made patterns. So a single template does not produce a single room. It produces a family of related rooms that share an overall shape and openings but differ in their details. With several templates per type, probabilistic tiles in each, and chunk substitutions inside them, the number of distinct possible rooms is very large, and every one of them respects the openings its type requires. Step four: monsters, items, and traps Once tiles are placed, the generator passes over the level and places entities. Rather than scattering them uniformly, it inspects each tile's neighbourhood. A spike trap is a candidate on a floor tile with solid ground below. A spider is a candidate on a ceiling tile with open space below it. An arrow trap is a candidate in a wall with a clear line of sight. Each candidate location is then filled with some probability. The rules are local and simple, but because they respond to the shape of the terrain, hazards end up in sensible positions. Step five: special cases On top of this, the game layers special rooms and level features: shops, altars, vaults, themed areas, and occasional level-wide variants such as dark levels. These are inserted by replacing particular rooms, usually off the solution path, with special templates. The core structure is unaffected. The path step in code The solution-path step is short enough to show in full, and writing it out makes clear how little machinery the guarantee needs. def solution_path(rng, cols=4, rows=4): types = [[0] * cols for _ in range(rows)] x, y = rng.randrange(cols), 0 start = (x, y) types[y][x] = 1 while True: r = rng.randrange(5) # 0,1 left; 2,3 right; 4 down dx = -1 if r < 2 else (1 if r < 4 else 0) if dx and 0 <= x + dx < cols: x += dx if types[y][x] == 0: types[y][x] = 1 continue # moving down: forced at an edge, or chosen types[y][x] = 2 # open at bottom if y == rows - 1: return types, start, (x, y) # exit room y += 1 types[y][x] = 3 # open at top Two details deserve attention. First, the bias toward horizontal moves is a design decision, not a mathematical one: with down chosen one time in five, the path tends to wander across each row before dropping, which spreads the level across the full width and avoids a single vertical shaft. Second, the code as written can mark a room as type 2 and then pass back through it horizontally, or overwrite a type 3 with a type 2 when the path drops twice in the same column. A real implementation needs a rule for combined openings, either a fourth type open on all sides or the convention that a room which needs both top and bottom openings uses a type 2 template with a guaranteed top gap. Kazemi's essay notes that the original handled such cases with specific template choices. Small edge cases like these are where most structure-first generators break, and they are cheaper to find by generating thousands of layouts in a test harness than by playing. Why it works The Spelunky model divides responsibility cleanly between three layers. The structure layer, the room grid and solution path, owns the global guarantees: the level is completable, the exit is reachable, the level has a sensible size. It is generated with simple randomness but is constrained so that every output satisfies the guarantees. The authorship layer, the templates and chunks, owns local quality. Every room was shaped by a human who knew how a player moves, so local jumps are possible, ledges are reachable, and spaces have character. Randomness inside templates adds variation, but the template author decided where variation is allowed. The population layer, entity placement, owns gameplay texture, using rules that read the terrain. None of these layers needs to know how the others work internally. The structure layer does not care what is inside a room. The templates do not care where in the level they appear. The population rules do not care how the terrain was made. That separation is why the generator is robust: each layer's correctness can be checked on its own. It is also why Spelunky levels feel fair. Players learn the game's grammar: they come to recognise that a gap in the floor of one room leads to the room below, that the exit is always toward the bottom, that a particular arrangement of tiles probably hides a trap. That learnability depends on the generator having a consistent structure. A generator that produced arbitrary layouts would deny players the pattern recognition that turns a roguelike from a lottery into a skill game. Variations on the model Many later games use variants of the same three-layer design, differing mainly in how they build the structure layer. Graph-based structure. Instead of a fixed grid, the structure can be a graph of rooms and connections, generated first and then laid out in space. Dead Cells (Motion Twin, 2018) uses this approach; its designers have described generating, for each biome, a level graph that specifies which hand-designed rooms are used and how they connect, with constraints on the number of special rooms, then placing the rooms so the connections line up. The graph holds the guarantees and pacing; the rooms hold the authored platforming. Grammar-based structure. Joris Dormans, in academic work and later in the game Unexplored (2017), used graph grammars to generate missions. A mission graph starts as a single abstract node, such as "dungeon", and rewriting rules replace nodes with subgraphs: a dungeon becomes an entrance, a sequence of challenges, and a boss; a challenge becomes a locked door, a key, and the path to the key. Because each rule preserves the solvability of the mission (a key is always placed reachable before its lock), the final mission is solvable by construction. A second stage turns the mission graph into a physical space. Unexplored emphasised what Dormans called cyclic generation, building levels around loops rather than trees, so that players encounter shortcuts, return paths, and locked doors seen before their keys are found. The idea of rewriting rules for structure foreshadows Chapter 6, where the same idea, applied to strings, grows plants. Binary space partitioning. Many traditional roguelikes, descending from Rogue (1980), generate dungeons by recursively splitting the map rectangle into smaller rectangles, placing a room in each leaf, and connecting sibling rooms with corridors. The tree of splits guarantees that every room connects to every other. The method is simple and fast but produces a recognisable rectilinear look. Room-and-corridor placement with repair. Another common approach places rooms at random, rejects overlaps, and then connects them using a minimum spanning tree over room centres plus a few extra edges to create loops. This works but has to verify connectivity explicitly, which is exactly the kind of after-the-fact checking the Spelunky model avoids. Where pure algorithms fit None of this means the techniques from earlier chapters are useless for level design. It means they work best inside a structure that owns the guarantees. A cellular automaton can shape the interior of a large cavern room once the structure layer has decided where the room's openings are. Noise can modulate the probability of tiles inside a template. A Spelunky-style grid can determine the macro layout while a noise field controls which areas are wetter, darker, or more dangerous. The reverse is also true. In large open worlds, where there is no single path to guarantee and the player can go anywhere, a template-based structure layer has less to offer, and continuous algorithms such as noise carry more of the load. Minecraft's terrain has no solution path; it does not need one, because the player can dig. But even Minecraft uses a structure-first, template-filled approach for its villages, temples, and strongholds, which are assembled from hand-built pieces using a jigsaw system that connects pieces at labelled joints. Wherever a feature must be coherent at a scale larger than a local rule can see, structure-first generation reappears. Seeds as a player-facing feature The Spelunky games also show that determinism, the contract from Chapter 1, can be a design feature in its own right rather than only an engineering convenience. Spelunky HD and Spelunky 2 include daily challenges in which every player gets the same generated levels on a given day and competes for the best score, with one attempt. Spelunky 2 lets players enter a seed to replay a specific run. Both features depend on the generator being exactly reproducible from a seed across machines. Both also change how players relate to the generator: a shared daily run becomes a common experience that players discuss, compare, and stream, which turns procedural content from something private and disposable into something social. Speedrunning communities for many procedural games have similarly organised categories around set seeds and random seeds, which only works if seeds behave consistently. The cost of templates The Spelunky model has a cost, and it is human time. Every template and chunk has to be designed, tested, and balanced. The variety of the output is bounded by the variety of the input. Players of any template-based game eventually start to recognise individual rooms, and at that point the illusion of endless novelty weakens. Designers mitigate this with more templates, more probabilistic tiles, more chunk substitutions, and mirroring of templates, but there is no escape from the fact that the output can only recombine what was authored. This is the trade-off that runs through all of procedural generation. Pure algorithms are cheap to author and produce unbounded variation, but the variation is often shallow and the guarantees are hard to establish. Authored fragments produce strong local quality and fairness, but their variation is bounded by human effort. The interesting techniques are the ones that move along that line: that let a small amount of authored input produce a large amount of coherent output. The remaining algorithm families in this booklet sit at different points on that line. L-systems, the subject of the next chapter, take a very small authored input, a handful of rewriting rules, and expand it into complex branching forms. Wave function collapse, in Chapters 8 and 9, takes an authored example or tile set and generates new layouts that are locally consistent with it everywhere. Both can be seen as attempts to get Spelunky's authored quality with less authoring. Chapter 6: L-Systems, Growing Plants from Strings In 1968 the Hungarian biologist Aristid Lindenmayer, working at the University of Utrecht, published a two-part paper in the Journal of Theoretical Biology titled "Mathematical models for cellular interactions in development". He was studying how simple multicellular organisms, filamentous algae and similar, grow. He wanted a formalism in which each cell's next state depends on its current state and possibly its neighbours, and in which all cells divide or change simultaneously, as they do in a living organism. The formalism he devised, now called a Lindenmayer system or L-system, is a kind of string-rewriting grammar. Two decades later, the computer scientist Przemyslaw Prusinkiewicz, working with Lindenmayer, showed that L-systems combined with a simple drawing scheme can produce strikingly realistic plants. Their 1990 book The Algorithmic Beauty of Plants remains the standard reference, and its authors' group at the University of Calgary has made it freely available online. For game developers, L-systems are the classic way to grow trees, shrubs, ferns, and flowers procedurally. They are also a clear illustration of the booklet's thesis: a few lines of grammar impose the branching habit of a species, and the randomness, when it is added, merely varies the details within that habit. Rewriting in parallel An L-system has three parts: an alphabet of symbols, an initial string called the axiom, and a set of production rules, each of which says how to replace one symbol with a string of symbols. To derive the next generation, replace every symbol in the current string simultaneously according to its rule. Symbols with no rule are copied unchanged. Lindenmayer's first example modelled the growth of an alga. It has two symbols, A and B, the axiom A, and two rules: A -> AB B -> A The generations are: n=0: A n=1: AB n=2: ABA n=3: ABAAB n=4: ABAABABA The lengths are 1, 2, 3, 5, 8, the Fibonacci numbers. That is a small hint of why L-systems model biology well: simple parallel rules produce growth patterns that appear throughout nature. The word "parallel" is the important distinction. In the formal grammars familiar from compilers and linguistics, called Chomsky grammars, one symbol is rewritten at a time. In an L-system, every symbol is rewritten at once in each step. That matches the biology, where every cell grows at the same time, and it is what gives L-systems their self-similar character: every branch grows according to the same rules at the same pace as every other branch, so the structure at small scale echoes the structure at large scale. The rewriting itself is trivially simple to implement: def derive(axiom, rules, n): s = axiom for _ in range(n): s = "".join(rules.get(c, c) for c in s) return s Turtle interpretation A string of symbols is not a plant. The step that turns L-systems into a graphics tool is to read the final string as a sequence of drawing commands for a turtle, an imaginary pen with a position and a heading, borrowed from the educational programming language Logo. Prusinkiewicz introduced this interpretation for L-systems in the mid-1980s. The basic two-dimensional commands are summarised in Table 4, along with the additional rotation symbols The Algorithmic Beauty of Plants uses for three dimensions. Table 4. Standard turtle interpretation of L-system symbols (after Prusinkiewicz and Lindenmayer). Symbol Turtle action Notes F Move forward one step, drawing a line A segment of stem or branch f Move forward without drawing Gaps, spacing + / − Turn left / right by angle δ Rotation about the up axis & / ^ Pitch down / up by δ Three-dimensional only \ / / Roll left / right by δ Three-dimensional only [ / ] Push / pop turtle state Start and end a branch With just F, +, and −, L-systems produce classic fractal curves. The quadratic Koch island, the Sierpinski triangle, and the dragon curve all have one-line L-system definitions. These are pleasant, but plants need one more idea. Branching Plants branch. A turtle that moves only forward and turns can draw a single continuous line but cannot draw a tree, because after drawing a branch it would have to retrace its path to return to the trunk. The square brackets solve this. [ pushes the turtle's current position and heading onto a stack; ] pops them off, returning the turtle to where it was when the matching [ was encountered. A bracketed substring is therefore a branch: the turtle goes out along it, draws, and snaps back to the branch point. A bracketed L-system from The Algorithmic Beauty of Plants that produces a convincing weed-like plant uses the axiom F, the rule F -> F[+F]F[-F]F, and a branching angle of 25.7 degrees, derived for five generations. Each segment of stem becomes three segments with a branch to the left after the first and a branch to the right after the second. After five generations, every original segment has been replaced by a structure of branches on branches, and the result looks like a recognisable plant silhouette. A second classic from the same book separates the growing tips from the stems by introducing a symbol that the turtle ignores: axiom: X X -> F[+X]F[-X]+X F -> FF angle: 20 degrees, n = 7 Here X is an apex, a growing tip that is not drawn. Each generation, every apex produces new stem segments and new apices on branches. Meanwhile every existing stem segment doubles in length (F -> FF), which models the elongation of older wood. The separation between apices and internodes is the key to modelling real plants, because in real plants growth happens at the tips, and the older parts of the plant thicken and lengthen without producing new structure. Drawing the result needs a stack and a few lines of trigonometry: def draw(s, step, angle_deg): x, y, heading = 0.0, 0.0, 90.0 stack, lines = [], [] for c in s: if c == "F": nx = x + step * cos(radians(heading)) ny = y + step * sin(radians(heading)) lines.append(((x, y), (nx, ny))) x, y = nx, ny elif c == "+": heading += angle_deg elif c == "-": heading -= angle_deg elif c == "[": stack.append((x, y, heading)) elif c == "]": x, y, heading = stack.pop() return lines The string grows exponentially One practical problem appears immediately. The string grows geometrically with the number of generations. The rule F -> F[+F]F[-F]F replaces one F with five, so after n generations the string contains about 5ⁿ F symbols: about 3,000 after five generations and about 390,000 after eight. Storing the string and interpreting it is fine for an offline tool but can be expensive at runtime, especially for many trees. Two techniques help. The first is to interpret the string recursively without ever building it: a function that "draws symbol c at depth d" either applies the turtle action, if d is zero, or recursively draws each symbol of c's replacement at depth d − 1. Memory use is then proportional to the depth, not the string length. The second, more important in games, is to generate trees offline or at load time, convert them to meshes, and instance a modest library of them across the world, which is how most games use procedural trees in practice. Stochastic L-systems A deterministic L-system produces the same plant every time. A field of identical trees looks artificial, so the first extension for games is randomness. In a stochastic L-system, a symbol can have several rules, each with a probability: F -> F[+F]F[-F]F (p = 0.33) F -> F[+F]F (p = 0.33) F -> F[-F]F (p = 0.34) At each rewriting step, each occurrence of F independently picks one of its rules. The resulting plants share a branching habit, since every rule produces the same kind of structure, but differ in their exact form. The Algorithmic Beauty of Plants shows a row of plants generated this way that look like individuals of the same species. To fit the determinism contract from Chapter 1, seed the choice from a positional hash of the plant's world location, so each tree is varied but reproducible. This is a clean demonstration of the booklet's argument. The rules constrain the plant to a species; randomness only selects among options the rules permit. Adding randomness without the rules gives scribbles. Adding rules without randomness gives clones. The interesting space lies where the grammar carries the structure and the randomness carries the individuality. Parametric and context-sensitive systems Real plants are not only branching structures. Their branches taper, their internodes vary in length, their leaves are arranged according to precise angles, and their growth responds to their surroundings. Two further extensions from the L-system literature handle this. Parametric L-systems attach numerical parameters to symbols and allow rules to compute new parameter values and to apply only when conditions hold: A(l, w) : l > 0.1 -> F(l, w) [ +(30) A(l*0.7, w*0.6) ] [ -(45) A(l*0.8, w*0.7) ] This rule says that an apex with length l and width w, as long as l exceeds 0.1, draws a segment of that length and width, then spawns two child apices with shorter lengths, narrower widths, and different branching angles. When the length falls below the threshold, the rule stops applying and growth ends. Parameters let a single rule express tapering, length decay, asymmetric branching, and termination conditions. Most tree generators used in practice are parametric in spirit, even if they do not use L-system notation. Context-sensitive L-systems let a rule depend on a symbol's neighbours in the string, written A < B > C -> X, meaning "replace B with X if it is preceded by A and followed by C". Because brackets are skipped when determining context, the neighbours in the string correspond to the neighbours in the plant: the segment below and the segment above. Context sensitivity lets signals propagate through the plant, which Prusinkiewicz and Lindenmayer used to model processes such as flowering that start at the base and travel up the stem, or hormones that inhibit branching near an apex. Later work by Prusinkiewicz and colleagues added environmental interaction: open L-systems that exchange information with a model of the environment, so that branches can sense light or obstacles and grow toward or away from them. That is the principle behind the space colonization algorithm discussed in the next chapter. Phyllotaxis and the golden angle One more piece of mathematics from The Algorithmic Beauty of Plants matters for games because it is cheap and immediately improves results: the arrangement of leaves and florets, called phyllotaxis. In many plants, successive leaves around a stem, or successive seeds in a sunflower head, are rotated by about 137.5 degrees from one another. This is the golden angle, the angle that divides a full turn in the golden ratio. Because the golden ratio is, in a precise sense, the most irrational number, rotations by the golden angle never line up into repeating rows, so leaves overlap as little as possible. The model of the sunflower head given by H. Vogel in 1979 and used in the book places the n-th seed at angle n times 137.5 degrees and radius proportional to the square root of n. A few lines of code produce the familiar interlocking spirals of a sunflower head, a pine cone, or a daisy. In a tree generator, rotating each successive branch around its parent by 137.5 degrees produces a far more natural distribution of branches than random or evenly spaced angles. A worked example: designing a conifer To make these ideas concrete, consider building a grammar for a stylised conifer, the kind of tree that fills the cold biomes of many games. A conifer has a strongly dominant central trunk, called excurrent growth, with whorls of side branches that are long near the base and short near the top, giving the familiar conical silhouette. Side branches droop slightly and do not themselves branch much. The first design decision is to separate the trunk apex from the branch apices, because they behave differently. Use T for the trunk tip and B for a branch tip, each carrying parameters. A parametric grammar might read: axiom: T(1.0) T(s) : s > 0.15 -> F(0.5) W(s) /(137.5) T(s*0.88) W(s) -> [&(70) B(s)] /(90) [&(70) B(s)] /(90) [&(70) B(s)] /(90) [&(70) B(s)] B(s) : s > 0.1 -> F(s) [-(35) B(s*0.4)] [+(35) B(s*0.4)] B(s*0.7) Each trunk step draws a segment, produces a whorl W of four branches pitched down 70 degrees and spaced 90 degrees apart, rolls the next whorl by the golden angle so whorls do not line up, and continues with a slightly smaller scale factor. Because s shrinks with every trunk step, branches higher on the trunk start smaller, which produces the cone. Each branch extends, sprouts two small side shoots, and continues at reduced scale until it falls below its threshold. The second decision is where randomness goes. Perturbing the whorl count (three to five branches), the pitch angle (60 to 80 degrees), and the scale decay (0.85 to 0.9) with a seeded generator produces trees that are clearly the same species but individually distinct. Perturbing the branching structure itself, for instance letting branches sometimes branch twice, quickly produces trees that look like a different species, which is a useful test of whether randomness has been put in the right place. The third decision is a correction for gravity. Adding a small downward pitch to every branch segment, proportional to its distance from the trunk, makes the outer ends of branches droop, which is the single change that most improves the realism of a conifer. In The Algorithmic Beauty of Plants this kind of bending toward a direction is called tropism and is modelled by rotating the turtle slightly toward a tropism vector at each step. The result is three rules and a handful of parameters that produce an unlimited supply of plausible conifers. Changing the scale decay, whorl count, and pitch range produces fir, spruce, or a stylised fantasy variant from the same grammar. That compactness, a species as a few lines of text, is the main reason L-systems remain attractive for games. Using L-systems in a game In shipped games, L-systems rarely appear in their pure textbook form. The usual pattern is: 1. Design species offline. An artist or technical artist builds a parametric, stochastic grammar for each species, tuning branching angles, decay rates, and probabilities until the silhouettes look right. 2. Generate a library. For each species, generate a set of variants from different seeds and convert each to a mesh, with leaves added as textured cards at branch tips. Generate lower-detail versions for distant rendering. 3. Place instances. At runtime, place instances of library trees across the terrain with random rotation and scale, using placement rules driven by the terrain and climate fields, which the next chapter covers. Commercial vegetation tools follow the same philosophy. SpeedTree, widely used in games and film, lets artists build trees from procedural branch generators with parameters such as length, angle, and frequency at each level of the hierarchy, then hand-edit the results. Its generators are not literally L-systems, but they encode the same insight: a plant is a hierarchy of similar branching rules, parameterised by level. A few pitfalls are common enough to name. Purely bracketed L-systems tend to produce flat, two-dimensional plants unless roll and pitch symbols are used. Branching angles that are constant at every level produce an obviously fractal look; real trees branch at wider angles near the base and narrower angles in the crown. Gravity matters: real branches droop under their own weight, which a simple turtle ignores, and adding a small downward rotation proportional to branch length improves realism considerably. And L-systems on their own know nothing about light. Real trees in a forest are asymmetric because they grow toward gaps in the canopy, and an L-system tree placed next to another will happily grow branches straight through its neighbour. That last point is the boundary of what a grammar can do on its own. A grammar describes how a plant grows from the inside. A forest is shaped as much by competition for space and light, by soil, by slope, and by water. The next chapter moves from individual plants to vegetation across a world. Chapter 7: From Plants to Forests A convincing tree is not a convincing forest. Walk through a real woodland and the arrangement of plants tells a story: tall trees spaced by competition for light, saplings clustered in gaps where an old tree fell, shrubs thickening at the forest edge, mosses on the shaded side of a slope, a sudden change of species where the soil turns wet. A procedurally generated world that scatters perfect L-system trees uniformly at random across its terrain looks wrong at a glance, even when each individual tree is excellent. This chapter covers the techniques that fill the gap: space colonization, which grows tree crowns that respond to the space around them; Poisson disk sampling and other blue-noise methods, which produce natural-looking spacing; and rule-based placement, which ties vegetation to the terrain and climate fields built in Chapter 3. As with every chapter so far, the techniques work by imposing structure on randomness, and the art lies in matching the structure to what nature actually does. Space colonization: growing toward the light L-systems describe growth from the inside out: each apex follows its rule regardless of what is around it. In 2007, Adam Runions, Brendan Lane, and Przemyslaw Prusinkiewicz published "Modeling Trees with a Space Colonization Algorithm", which inverts that relationship. The tree's form emerges from competition for space rather than from a fixed grammar. The method grew out of earlier work by Runions and colleagues on generating the vein patterns of leaves. The algorithm works like this: 1. Define the envelope of the crown, the volume the tree's canopy may occupy: a sphere, an ellipsoid, a cone, or any shape an artist draws. Fill it with a large number of randomly placed attraction points. These represent available space, or light. 2. Start with a single node at the base of the trunk. 3. For each attraction point, find the nearest tree node within a radius of influence. Each point influences only its nearest node. 4. For each node influenced by at least one attraction point, compute the average of the normalised directions from the node to its influencing points. Grow a new node one step along that direction. 5. Remove any attraction point that now has a tree node within a smaller kill distance. That space has been occupied. 6. Repeat until no attraction points remain or no node is influenced. while attractors: influence = defaultdict(list) for a in attractors: n = nearest_node(a, max_dist=RADIUS_INFLUENCE) if n: influence[n].append(normalize(a - n.pos)) if not influence: break for n, dirs in influence.items(): d = normalize(sum(dirs)) add_node(parent=n, pos=n.pos + STEP * d) attractors = [a for a in attractors if not any_node_within(a, KILL_DIST)] The behaviour that emerges is plausibly tree-like. Branches spread to fill the crown evenly, because points near existing branches are consumed and points in empty regions keep attracting growth. Branches avoid each other, because they compete for the same points. When the envelope is asymmetric, or when another tree's crown has already consumed attraction points on one side, the tree grows lopsided toward open space, as real trees do at a forest edge. Changing the density of attraction points, the radius of influence, and the kill distance produces quite different species-like habits, from dense rounded crowns to sparse, open ones. Branch thickness is computed afterwards. A common rule, derived from observations attributed to Leonardo da Vinci and used by Runions and colleagues, is that the cross-sectional area of a branch roughly equals the sum of the areas of its children. Working back from the tips, each node's radius is set from its children's radii, so the trunk ends up thick and the twigs thin. For games, space colonization's main advantage over L-systems is controllability. An artist specifies the silhouette of the crown directly by drawing the envelope, and the algorithm fills it naturally. It is also straightforward to make several trees compete by sharing a single set of attraction points, which produces canopies that interlock without intersecting. Its main cost is nearest-neighbour searches, which need a spatial index such as a grid or k-d tree to stay fast with thousands of points. Why uniform random scatter looks wrong Before placing trees, it is worth understanding why the obvious approach fails. Picking positions uniformly at random, each independent of the others, produces what statisticians call a Poisson point process, or more loosely white noise. It has a property that surprises people: it clumps. With independent positions, some points inevitably land close together and some regions are left empty. The eye reads clusters and voids as structure, and a uniformly random forest looks patchy in a way that real forests do not. Real trees are not independent. A mature tree suppresses competitors within some distance because it takes their light, water, and nutrients. The result is a distribution where points are random but rarely closer than a minimum distance. In the vocabulary of signal processing, this has a blue-noise spectrum: little energy at low frequencies, meaning no large clumps or voids, and random variation at higher frequencies, meaning no visible grid. The same distribution appears in the photoreceptors of the retina, and it is what dithering algorithms aim for when they arrange dots in a printed image. The opposite failure is to place trees on a regular grid with a little random jitter. A jittered grid avoids clumps, but if the jitter is small the grid shows through, especially when viewed along its rows, and if the jitter is large the clumping returns. Poisson disk sampling The direct way to get a blue-noise distribution is Poisson disk sampling: generate random points with the constraint that no two are closer than a minimum distance r. The naive implementation, "throw random points and reject any that are too close", slows to a crawl as the space fills, because almost every candidate is rejected. Robert Bridson's 2007 SIGGRAPH sketch, "Fast Poisson disk sampling in arbitrary dimensions", gave the method most games use. It runs in time proportional to the number of points produced: 1. Create a background grid with cells of side r divided by the square root of the number of dimensions, so each cell can hold at most one sample. This makes "is any point within r?" a check of a few nearby cells. 2. Place an initial random point, add it to the output and to an active list. 3. While the active list is non-empty, pick a random active point. Generate up to k candidates (Bridson suggests k = 30) uniformly in the annulus between r and 2r around it. For each candidate, check the grid for neighbours within r. Accept the first valid candidate, adding it to the output and the active list. If all k candidates fail, remove the point from the active list. The result is a set of points that fills the space with roughly uniform density, no two closer than r, and no visible regularity. Using it for tree placement immediately makes a forest look more natural. In code, the core of the method is compact: def poisson_disk(rng, w, h, r, k=30): cell = r / sqrt(2) gw, gh = int(w / cell) + 1, int(h / cell) + 1 grid = [[None] * gw for _ in range(gh)] def fits(p): gx, gy = int(p[0] / cell), int(p[1] / cell) for yy in range(max(gy - 2, 0), min(gy + 3, gh)): for xx in range(max(gx - 2, 0), min(gx + 3, gw)): q = grid[yy][xx] if q and dist(p, q) < r: return False return True first = (rng.uniform(0, w), rng.uniform(0, h)) pts, active = [first], [first] grid[int(first[1] / cell)][int(first[0] / cell)] = first while active: i = rng.randrange(len(active)); p = active[i] for _ in range(k): a, d = rng.uniform(0, 2 pi), rng.uniform(r, 2 r) c = (p[0] + d cos(a), p[1] + d sin(a)) if 0 <= c[0] < w and 0 <= c[1] < h and fits(c): pts.append(c); active.append(c) grid[int(c[1] / cell)][int(c[0] / cell)] = c break else: active.pop(i) return pts The check examines a five-by-five block of grid cells around the candidate, because with cells of side r divided by the square root of two, any point within distance r must lie within two cells in each direction. The result is deterministic for a given seeded generator, which keeps it inside the contract of Chapter 1. Variable density Real forests are not uniformly dense. The minimum distance itself should vary across the world: small in a dense jungle, large in an open savanna, infinite above the treeline. Bridson's algorithm extends naturally to a spatially varying radius: when checking a candidate, use the radius defined at that location, read from a density map. That density map can come straight from the noise and climate fields of Chapter 3. Chunk-safe blue noise Poisson disk sampling has the same locality problem as cellular automata. Whether a point is accepted depends on points already placed, so two chunks generated independently can produce trees too close together across their shared edge. Three common solutions exist. The first is to generate points in each chunk with a margin and a priority order. Points are generated in a deterministic order from positional hashes, and any point closer than r to a higher-priority point, including one in a neighbouring chunk's margin, is discarded. Both chunks reach the same verdict about the shared region. The second is to precompute a tileable blue-noise pattern, a square of points whose distribution wraps seamlessly at its edges, and repeat it across the world, using noise thresholds to decide which points actually receive a tree. Repetition of the underlying pattern is rarely visible once density variation is applied. Research on Wang tiles for blue noise, such as work by Michael Cohen and colleagues in 2003 and Johannes Kopf and colleagues in 2006, developed ways to tile point sets without visible periodicity. The third is to use a jittered grid with a cell size close to r and accept the small amount of regularity. For dense undergrowth, which the player sees at close range but never in long straight lines, this is often good enough and far cheaper. Rule-based placement Spacing is only half the problem. The other half is deciding what grows where. Here the generator returns to the field-based pipeline of Chapter 3. Each candidate point, produced by Poisson disk sampling or a jittered grid, is evaluated against a set of rules for each candidate species: • Altitude: pines above a certain height, palms near sea level, nothing above the treeline. • Slope: trees on gentle slopes, shrubs on moderate ones, bare rock on cliffs. Slope comes from the heightmap's gradient, which noise can provide analytically. • Climate: species chosen by the temperature and humidity fields. • Distance to features: reeds near water, wildflowers in clearings, no trees on roads. • Clustering noise: a separate low-frequency noise field that adds patchiness, so that species form groves rather than being mixed uniformly. Each rule produces a suitability score, and the species with the highest score, or one chosen randomly weighted by score, is placed. Rules are evaluated per point and are purely local, so they are chunk-safe. Guerrilla Games described an advanced version of this approach at GDC in 2017 in Jaap van Muijden's talk on GPU-based procedural placement in Horizon Zero Dawn. Artists authored placement rules as networks of operations over world data maps, such as height, slope, water proximity, and painted masks, producing a density value for each type of asset at every point. The density maps were evaluated on the GPU and converted to discrete placements with a dithering step, all in real time in tiles around the camera, so the dense vegetation of a large open world never had to be stored. Designers could still override any area by painting into the input maps. The approach demonstrates two lessons: rules over fields scale to an entire world, and keeping the artist's hand in the loop, through painted masks and rule editing, is what makes the result look designed rather than generated. Layering Natural vegetation has layers: canopy trees, understorey trees, shrubs, ground cover. Each layer constrains the next. A practical placement pipeline mirrors that: 1. Place the largest trees first, with Poisson disk sampling at a large radius and the strictest rules. 2. Place understorey trees with a smaller radius, rejecting candidates within a minimum distance of canopy trees. 3. Place shrubs, preferring locations near but not under the canopy, which gives the dense forest-edge band that real woodlands have. 4. Place ground cover with a jittered grid and density driven by how much canopy is overhead: dense grass in clearings, sparse ferns and moss under trees. Each layer reads the output of the layers above it, so the vegetation develops a believable structure without any explicit ecosystem simulation. This is the pipeline principle from Chapter 1 again: each stage is simple, but the order of stages and their dependencies produce complex results. Rendering budgets shape placement Placement is also constrained by what the renderer can draw. A forest of a million unique trees is not feasible; a forest of a million instances of thirty tree meshes is routine, because modern engines draw instanced geometry cheaply. That fact feeds back into generation. The species library from Chapter 6 should be designed with a fixed instance budget in mind, and placement should add apparent variety through instance-level parameters that cost nothing to render differently: rotation about the vertical axis, uniform scale within a modest range, a slight lean, and a per-instance colour tint. Distance matters as well. Ground cover that is dense near the camera can thin out with distance, since nobody can see individual grass blades at a hundred metres, and the placement rules can encode that falloff directly rather than leaving it to the renderer. Generation and rendering budgets are, in practice, one design problem. Ecosystem simulation The most physically grounded approach is to simulate the ecosystem itself. In 1998, Oliver Deussen, Pat Hanrahan, Bernd Lintermann, Radomír Měch, Matt Pharr, and Przemyslaw Prusinkiewicz published "Realistic modeling and rendering of plant ecosystems" at SIGGRAPH. Their method placed plants by simulating, over many virtual years, seeding, growth, and competition: plants were represented as circles that grew over time, and when two circles overlapped the smaller plant could be dominated and die. Species had different growth rates and tolerances. The resulting distributions showed the clustering, self-thinning, and species zonation of real plant communities. Simulation produces the most natural distributions but has the usual costs: it is iterative, global, and slow compared with direct placement. Games that use it typically run it offline on a bounded area and save the result, or run it on a coarse grid and use the output as a density map for fast runtime placement. As with erosion in Chapter 3, the common compromise is to use simulation to understand what distributions look like, then approximate them with local rules that capture the visual result without the global dependency. Where this leaves the generator At this point, the booklet's pipeline can produce a world with shaped terrain, climate, biomes, caves, and believable vegetation. All of these techniques share a family resemblance. They impose local constraints, smoothness in noise, agreement in automata, grammar in L-systems, spacing in Poisson sampling, suitability in placement rules, and let structure emerge. What none of them can do well is produce built environments: towns, buildings, interiors, any structure where parts must fit together exactly according to rules of construction. A wall must meet a wall; a roof must sit on walls; a door must open onto a floor, not a void; a street must connect to other streets. These are adjacency constraints of a hard, combinatorial kind, and they need a different class of algorithm. In 2016 Maxim Gumin published one that became, almost overnight, one of the most discussed techniques in procedural generation: wave function collapse. Chapter 8: Wave Function Collapse, Constraints as Content In September 2016, Maxim Gumin posted a repository to GitHub called WaveFunctionCollapse. Its README showed small input images, a few pixels across, of brick patterns, cave maps, flowers, and abstract knots, alongside much larger output images that looked like new, original continuations of the inputs. The outputs were never copies. They were new arrangements that, at every local patch, looked exactly like some part of the input. Within weeks, developers and artists were posting their own experiments: dungeons, circuit boards, pixel-art towns, three-dimensional voxel buildings. The repository, released under the MIT licence, became one of the most influential pieces of code in procedural generation. The algorithm's name, borrowed loosely from quantum mechanics, makes it sound more mysterious than it is. Wave function collapse, usually shortened to WFC, is a constraint solver. It takes a set of local rules, which pieces may sit next to which, and fills a grid with pieces that satisfy every rule everywhere. Its importance for games is that it lets designers specify content by example or by adjacency, rather than by writing a generator, and it produces output with a level of local coherence that noise and automata cannot reach. The problem WFC solves Consider building a town on a grid out of tiles: straight road, corner road, T-junction, crossroads, building front, building corner, park, river, bridge. Each tile has edges, and each edge has a type: road, pavement, grass, water. A valid town is one in which every pair of adjacent tiles has matching edges. A road edge must meet a road edge; water must meet water. Picking tiles at random almost never produces a valid town. Picking tiles one at a time and choosing each to fit its already-placed neighbours works for a while, then fails: eventually a cell is reached whose neighbours demand an edge combination no tile provides, and the generator is stuck. What is needed is a method that, at every step, keeps track of which tiles remain possible in every cell and makes choices that keep the whole grid solvable for as long as possible. That is what WFC does. The core loop WFC maintains, for every cell in the output grid, a set of tiles (or patterns) that are still possible there. Gumin calls the collection of these sets the wave, by analogy with a quantum superposition: each cell is "in superposition" over its remaining possibilities until it is "observed". At the start, every cell can be any tile. The algorithm then repeats two steps. Observation. Choose the cell with the fewest remaining possibilities, more precisely the lowest entropy, and collapse it: pick one of its remaining tiles at random, weighted by how frequent that tile is, and remove all the others. If the chosen cell has zero possibilities, the algorithm has hit a contradiction. Propagation. The collapsed cell now constrains its neighbours. For each neighbour, remove any tile that cannot sit next to any tile still possible in the collapsed cell. If that removes possibilities from the neighbour, the neighbour in turn may constrain its own neighbours, so add it to a work queue. Continue until no further removals occur. When every cell has exactly one possibility, the output is complete and, by construction, satisfies every adjacency rule. def wfc(grid_cells, tiles, compatible, weights, rng): wave = {c: set(tiles) for c in grid_cells} while True: open_cells = [c for c in grid_cells if len(wave[c]) > 1] if not open_cells: return wave # solved c = min(open_cells, key=lambda c: entropy(wave[c], weights) + rng.random() * 1e-6) t = weighted_choice(wave[c], weights, rng) wave[c] = {t} if not propagate(wave, c, compatible): return None # contradiction def propagate(wave, start, compatible): stack = [start] while stack: c = stack.pop() for d, n in neighbours(c): allowed = set().union(*(compatible[t][d] for t in wave[c])) new = wave[n] & allowed if new != wave[n]: if not new: return False wave[n] = new stack.append(n) return True Here compatible[t][d] is the set of tiles that may appear in direction d from tile t. This is the whole algorithm in its simplest form. Everything else is efficiency, heuristics, and handling contradictions. Why lowest entropy? The choice of which cell to collapse next matters a great deal. Collapsing cells in scanline order, left to right and top to bottom, tends to paint the generator into corners, because decisions are made far from the constraints that will eventually conflict with them. Choosing the most constrained cell, the one with the fewest options, follows a heuristic well known in constraint satisfaction, sometimes called "minimum remaining values" or "fail first". If a cell is going to cause trouble, it is better to find out early, while there is still freedom elsewhere to accommodate it. Gumin's implementation measures constraint by Shannon entropy rather than by a simple count of options. Entropy takes the tile weights into account: a cell with two options, one of which is very common and one very rare, is almost decided, and has lower entropy than a cell with two equally likely options. A tiny random value is added to break ties, so collapse does not proceed in a predictable order. The visual effect of lowest-entropy ordering is distinctive. Generation starts at a random point and spreads outward like a crystal growing, because each collapse reduces the entropy of its neighbours and makes them the next candidates. Two models: overlapping and tiled Gumin's repository includes two ways of defining the adjacency rules, summarised in Table 5. Table 5. The two models in Gumin's WaveFunctionCollapse repository. Aspect Overlapping model Simple tiled model Input A small example bitmap A tile set plus adjacency rules Unit in the wave N×N pixel pattern from the input Whole tile Adjacency defined by Patterns agreeing on their overlap Explicit neighbour list (XML) Weights from Pattern frequency in the input Author-specified per tile Typical use Texture-like layouts, maps from samples Modular buildings, roads, levels The overlapping model The overlapping model learns its rules from an example image. Choose a pattern size N, commonly three. Slide an N-by-N window over every position in the input, optionally including rotated and reflected copies, and record every distinct pattern along with how often it occurs. Two patterns are compatible in a given direction if, when one is offset from the other by one pixel in that direction, they agree on every pixel where they overlap. The wave then holds, for each output cell, the set of patterns that could be centred (or anchored) there. When the wave is fully collapsed, each output pixel takes its colour from its pattern. Because neighbouring patterns overlap and agree, every N-by-N window in the output appears somewhere in the input. That is the precise sense in which the output "looks like" the input: it is locally indistinguishable from it at scale N, while being globally new. The overlapping model is powerful because it requires no tile design. A designer draws a small sample, perhaps a ten-by-ten sketch of a dungeon with rooms, corridors, and doors, and WFC produces arbitrarily large dungeons in the same style. The choice of N is a trade-off. With N = 2, the output captures only pixel adjacencies and loses larger structure. With N = 3, it captures structures like corridor widths and corners. With larger N, it captures more, but the number of distinct patterns grows, the output tends to copy larger pieces of the input verbatim, and contradictions become more frequent because there are fewer ways to combine patterns. The simple tiled model The tiled model works with explicitly designed tiles and explicitly stated adjacency rules. Gumin's examples use XML files listing tiles and their allowed neighbours, along with a symmetry class for each tile, which tells the system which rotations and reflections of the tile exist and are distinct. A plain grass tile is fully symmetric; a straight road has two distinct rotations; a corner has four; an asymmetric tile has eight once reflections are included. Declaring symmetry once lets the system generate all rotated variants and their adjacencies automatically, which cuts down authoring work dramatically. In practice, most game developers who use WFC use a tiled model, often with adjacency rules derived automatically from edge labels. Each tile edge, or in three dimensions each face, is labelled with a socket type, and two tiles are compatible in a direction if their facing sockets match. This is the formulation used by most three-dimensional WFC building generators. WFC as constraint satisfaction When WFC became popular, much of the discussion treated it as a new invention. It was not, and understanding its ancestry makes it easier to use and extend. In 2017, Isaac Karth and Adam M. Smith published "WaveFunctionCollapse is Constraint Solving in the Wild" at the Foundations of Digital Games conference. They showed that WFC is an instance of a well-studied class of algorithms for constraint satisfaction problems: a set of variables (the cells), each with a domain of possible values (the tiles), and a set of constraints between pairs of variables (adjacency). The propagation step is a form of arc consistency, a standard technique that removes values from a variable's domain when they have no support in a neighbouring variable's domain. The observation step, choosing the most constrained variable and assigning a value, is the minimum-remaining-values heuristic. What WFC lacks, compared with a full constraint solver, is systematic backtracking: when it hits a contradiction, the original implementation simply restarts. Karth and Smith also demonstrated that the same problem could be handed to a general-purpose answer set programming solver, which could add global constraints that WFC itself could not express, such as "the output must contain exactly one exit" or "every room must be reachable". That observation is important for practitioners. WFC's local constraints guarantee local coherence but say nothing about global properties. If a level needs connectivity, a minimum number of rooms, or a path from start to finish, WFC must either be combined with a global check, or the global structure must be imposed first, as in the Spelunky model, with WFC filling in the details. WFC's other ancestor is model synthesis, developed by Paul Merrell. His 2007 paper "Example-based model synthesis" and later work with Dinesh Manocha generated large three-dimensional models, such as buildings and terrain, from small examples, using an algorithm with the same essential structure: adjacency constraints derived from an example, propagation of constraints, and assignment of values. Merrell's method collapses cells in scanline order rather than by lowest entropy, and generates large outputs by modifying them in blocks, an idea Chapter 9 returns to because it is the key to infinite generation. Gumin acknowledged model synthesis as related work, and Merrell later wrote a detailed comparison of the two methods. Contradictions and how to handle them Contradictions are the central practical problem with WFC. A contradiction occurs when propagation empties some cell's set of possibilities. It means that the earlier choices cannot be completed into a valid solution. How often contradictions occur depends on the tile set. Some tile sets essentially never contradict: if there is a "wildcard" tile, such as plain grass, that can sit next to almost anything, then almost any partial assignment can be completed. Other tile sets, especially overlapping-model inputs with large N or tiled sets with many specific, narrow constraints, contradict frequently. There are four main strategies: Restart. Discard the output and start again with a new seed. This was Gumin's original approach and works fine for small outputs with a low contradiction rate. It is useless for large outputs, where the probability of completing without contradiction falls toward zero. Backtracking. Keep a history of collapse decisions and the domain states before each one. On contradiction, undo the most recent decision, remove the choice that was made from that cell's options, and continue. This turns WFC into a standard depth-first constraint solver. It always finds a solution if one exists but can take exponential time in the worst case, and it needs memory for the history. In practice, limited backtracking, undoing a bounded number of steps, recovers from most contradictions. Local repair. Merrell's block-modification approach and its descendants reset a small region around the contradiction to full superposition, possibly while keeping its boundary fixed, and re-solve just that region. This is the method that scales to large and infinite worlds. Tile set design. The most effective strategy is to avoid contradictions by designing tile sets that are permissive. Include tiles that can transition between incompatible types. Avoid tiles that require very specific configurations of all their neighbours. Test a tile set by generating many outputs and measuring the contradiction rate before committing to it. Making WFC fast A naive implementation recomputes allowed sets by scanning every tile in a cell for each neighbour, which is slow for large tile sets. Production implementations use two standard optimisations. First, represent each cell's domain as a bitset, one bit per tile. Intersection and union become bitwise AND and OR, which are very fast and, with a few hundred tiles, fit in a handful of machine words. Second, keep support counts. For every cell, tile, and direction, store how many tiles in the neighbouring cell support this tile. When a tile is removed from a cell, decrement the counts it contributed to its neighbours. When any count reaches zero, that tile has lost all support from that direction and must be removed. This is the approach used in the reference implementation and corresponds to the more efficient arc-consistency algorithms in the constraint-satisfaction literature. It makes propagation cost proportional to the number of removals rather than the size of the domains. What WFC is good at, and what it is not WFC is excellent at producing outputs that are locally consistent with a style: pixel-art maps, building facades, dungeon layouts, pipe networks, tiled terrain, modular three-dimensional architecture. It lets a designer author a style rather than a generator. Small changes to the input or tile set produce predictable changes in the output, which makes it pleasant to iterate on. It is poor at global structure. It has no concept of distance, scale, or purpose. A WFC dungeon may have rooms that are not connected, corridors that loop pointlessly, or no exit at all. Its output tends to be statistically uniform: the same mix of features everywhere, with no sense of a town centre and outskirts or of a level's beginning and end. The solutions are the ones this booklet keeps returning to. Constrain WFC with structure imposed from above: pre-collapse certain cells to fix a road network, a coastline, or the entrance and exit; bias tile weights spatially with noise fields so that dense buildings cluster in the centre and parks at the edge; or run WFC inside the rooms of a structure-first layout rather than over the whole level. With these additions, WFC can build towns. The next chapter looks at how to make those towns infinite, how to solve on grids that are not square, and what Oskar Stålberg learned building Bad North and Townscaper. Chapter 9: Infinite Cities A wave function collapse solver running on a fixed grid of fifty by fifty cells is a pleasant afternoon project. A city that extends in every direction as the player walks, stays consistent if the player turns around, looks the same to two players who share a seed, and never gets stuck on a contradiction is a serious engineering problem. It is also the problem that the phrase "infinite city layouts" implies. This chapter takes WFC to that scale. It covers the boundary problem that arises when a constraint solver meets chunked generation, the block-modification approach that solves it, deterministic alternatives that trade some freedom for reproducibility, and the hierarchy of techniques, borrowed from decades of research on procedural cities, that gives a city the large-scale structure WFC cannot provide on its own. It ends with the work of Oskar Stålberg, whose games Bad North and Townscaper show what happens when the grid itself becomes a design material. The boundary problem The terrain and vegetation techniques of earlier chapters are local: the value at a point depends only on the seed and the point, or on a bounded neighbourhood. WFC is not local. A decision in one cell propagates through the grid, potentially across the whole output, and the solution in one region depends on choices made in another. That non-locality is what makes WFC good at coherence, and it is what makes infinite generation hard. Suppose the world is divided into chunks of, say, sixteen by sixteen cells, and each chunk is solved with WFC when the player approaches. Three approaches suggest themselves, and each has a flaw. Solve each chunk independently. The tiles along the edge of one chunk will almost never match the tiles along the edge of its neighbour. The seams are visible everywhere: roads that end abruptly, walls that stop halfway. Solve each chunk with its already-generated neighbours as fixed boundaries. When a new chunk is generated, pre-collapse its edge cells to whatever is compatible with the neighbouring chunks that already exist, then solve the interior. This produces seamless results, but it has two problems. First, a chunk surrounded on several sides by existing chunks is heavily constrained and may have no solution at all; the constraints imposed by its neighbours might be mutually incompatible. Second, the result depends on the order in which chunks are generated. Walk north then east, and the chunk at the north-east corner is constrained by different neighbours than if you walk east then north. Two players with the same seed will see different cities, which breaks the contract from Chapter 1. Solve a huge region in advance. This works for bounded worlds but is not infinite. The real solutions accept that a constraint solver cannot be purely local and find ways to contain its non-locality. Modifying in blocks Paul Merrell's model synthesis work, mentioned in Chapter 8, introduced the key technique: generate a large output by repeatedly modifying it in blocks. Start with a complete, valid but trivial output, for example a world filled entirely with a "ground" tile that can neighbour itself. Then choose a block, a region smaller than the whole. Reset the cells inside the block to full superposition while leaving everything outside fixed, and run the solver on the block alone, with the fixed cells around it acting as boundary constraints. If the solver succeeds, the block is replaced with its new contents, and the whole output remains valid, because the new interior is consistent with the unchanged exterior. If the solver fails, the block is left as it was. Then choose another block, overlapping the first, and repeat. Two properties make this work. The output is valid at every step, because each modification preserves consistency with the fixed surroundings. And because each block is small, contradictions are cheap: a failed block costs only the time to solve that block, not a restart of the world. Over many overlapping modifications, the trivial starting state is replaced by rich, varied content. For infinite worlds, the same idea applies with blocks generated as the player explores. The developer who writes under the name Boris the Brave, author of the open-source DeBroglie constraint-based generation library, has written about adapting Merrell's block modification to unbounded worlds in this way. The essential requirement is a starting state that is valid everywhere without any computation, the all-ground world, so that every unexplored region is already a valid, if boring, boundary for its neighbours. Block modification still has the order-dependence problem: the content of a block depends on which neighbouring blocks were modified before it. For a single-player game where the world is saved as it is generated, that is acceptable. The world is consistent once created, even if a different exploration route would have created a different one. Marian Kleineberg's widely shared infinite-city demo, built in Unity and published with its source in 2019, took this kind of approach. It generated a three-dimensional city of modular blocks around the player as they walked, used backtracking to recover from contradictions, and treated the generated world as persistent. It made no promise that a different route would produce the same city, and for a walking experience it did not need to. Deterministic infinite WFC When determinism matters, as it does for shared seeds, multiplayer, or streaming worlds that discard and regenerate distant chunks, the solution is to remove the dependency between chunks entirely by fixing their boundaries in advance with a purely local rule. The pattern looks like this: 1. Fix chunk boundaries by hash. For every edge between two chunks, determine the tiles along that edge from a positional hash of the edge's coordinates and the seed, chosen from a restricted set of boundary configurations that are known to be completable. Both chunks compute the same edge, because it depends only on the edge's position. 2. Solve each chunk with its edges pre-collapsed. Each chunk's interior is solved independently, with its four edges fixed. Because the edges were chosen from known-completable configurations, solutions exist. 3. Retry within the chunk. If a chunk hits a contradiction, retry its interior with a derived seed. The edges never change, so retrying does not affect neighbours. The cost is freedom. Constraining edges to a restricted set produces visible regularity if the set is small: every chunk boundary might cross the same few road positions. Designers mitigate this by making the boundary set large, by choosing chunk sizes larger than the scale of the repeated features, and by making edge configurations depend on the large-scale structure described below, so that boundaries look motivated rather than arbitrary. A common variant uses a coarse grid first. A low-resolution layer, such as a grid of city blocks each eight chunks across, is generated by hash: which coarse cells are dense centre, residential, park, or water, and where the main roads run. That layer fixes the chunk boundaries along the main roads. WFC then fills in everything between them. This is the hierarchical idea that runs through all serious city generators. Structure from above WFC produces local coherence. Cities have structure at every scale above the local: districts with characters, arterial roads that connect districts, smaller streets inside blocks, building lots along streets, buildings on lots, and facades on buildings. Procedural city research has addressed each of those scales, and the most effective game generators combine those techniques with WFC rather than asking WFC to do everything. Road networks. In 2001, Yoav Parish and Pascal Müller presented "Procedural Modeling of Cities" at SIGGRAPH. They generated road networks with an extended L-system, the same kind of rewriting grammar as Chapter 6, where each production proposes a new road segment and a set of external functions adjusts the proposal according to global goals (follow a grid pattern, a radial pattern, or population density) and local constraints (avoid water, snap to nearby intersections, do not cross existing roads at shallow angles). The result was a road network shaped both by planning patterns and by terrain. The method was the foundation of the CityEngine software. Later work, such as Guoning Chen and colleagues' 2008 paper "Interactive Procedural Street Modeling", generated streets by tracing lines through tensor fields, which gives designers smooth control over street orientation across a city. Districts and blocks. Districts can be defined by Worley noise or Voronoi regions, as in Chapter 2, with each region assigned a type that drives the tile weights used inside it. Blocks are the polygons enclosed by the road network; lots are produced by subdividing blocks, typically by recursively splitting them along their longest axis until each piece is a plausible building size with road frontage. Buildings. Pascal Müller and colleagues' 2006 paper "Procedural Modeling of Buildings" introduced CGA shape, a shape grammar in which rules repeatedly split a building's mass into floors, floors into bays, and bays into windows, doors, and wall segments. Shape grammars and WFC are complementary. Shape grammars excel at hierarchical subdivision with clear semantics: this is a ground floor, this is a cornice. WFC excels at filling a volume with modules that fit together. Many building generators use a grammar to set up the mass and a WFC-style solver to choose modules for the details. In a complete infinite city, each layer is a deterministic function of the seed and the layers above it, and each layer imposes constraints on the next. Districts set the weights. Roads fix the boundaries. Lots define the regions. WFC fills the regions with coherent detail. The non-locality of WFC is confined within boxes whose edges were set by local rules, which is what lets the whole system stay infinite and reproducible. Oskar Stålberg: Bad North and Townscaper The most celebrated uses of WFC in shipped games come from Oskar Stålberg, a Swedish developer and technical artist. His work makes two contributions beyond the basic algorithm: it treats WFC as a real-time, interactive system, and it moves WFC off the square grid. Bad North (Plausible Concept, 2018) is a real-time tactics game set on small, procedurally generated islands. Stålberg built the island generator with WFC over three-dimensional modules: cliffs, beaches, grass, buildings, stairs, each designed to connect to others along labelled faces. In talks about the game, he has described using the algorithm to generate islands that are both visually coherent and playable, with additional checks to ensure that the generated terrain suits the game's tactics, such as having enough navigable space and landing points for invading boats. It is a case of the structure-plus-constraints pattern at small scale: WFC provides the coherent look, and gameplay rules filter or shape the results. Townscaper, released in early access in June 2020 and fully in 2021, published by Raw Fury, is not really a game. It has no goals. The player clicks on water to add a block and clicks again to remove it, and the town assembles itself around those clicks: houses with pitched roofs, arches where a gap opens beneath a building, stairways where heights change, little gardens and balconies on rooftops, bridges, and lamp posts. Its appeal is that the town seems to understand what the player meant. Two ideas make that possible. The irregular grid. Townscaper does not use a square grid. Stålberg has explained the construction in talks and on social media: start with a large hexagon divided into triangles; randomly merge adjacent pairs of triangles into quadrilaterals; subdivide every remaining shape, triangles and quadrilaterals alike, into smaller quadrilaterals, so that the whole region is covered by four-sided cells; then relax the grid, repeatedly nudging vertices toward positions that make the quadrilaterals as close to squares as possible. The result is a grid in which every cell has four sides, as a square grid would, but the cells vary in shape and orientation organically. Because every cell is still a quadrilateral, modules designed for a square cell can be deformed to fit any cell of the irregular grid. Streets curve, plazas open at odd angles, and buildings stand at slightly different orientations, which removes the rigid gridded look that most modular construction systems have. The dual grid and corner-based modules. The player does not place modules directly. The player marks grid vertices as filled or empty at each height. Each cell of the grid, as a three-dimensional box between two heights, has eight corners, and the pattern of filled and empty corners determines what kind of geometry must occupy that cell: a solid wall section, an outer corner, an inner corner, a roof edge, empty air. This is the same idea as the marching cubes algorithm used in medical imaging and voxel terrain: classify each cell by its corner states and look up the matching geometry. Because the module set covers every corner configuration, there is always at least one piece of geometry that fits. WFC then works on top of this. Where several modules fit a configuration, the solver chooses among them while respecting adjacency rules with neighbouring cells, so that an arch appears only where the configuration and the neighbours support one, a staircase connects two levels coherently, and decorative elements form consistent patterns. Because the player is effectively editing constraints, the solver has to re-solve a local region after every click, quickly enough to feel instant, and it must not fail. The guarantee that a basic fitting module always exists for every corner pattern is what makes failure impossible: in the worst case the solver falls back to plain pieces, and the decorative variety is layered on top of a foundation that is always valid. Townscaper is a clean illustration of the booklet's thesis. The player supplies almost no information: a set of filled points. The grid construction imposes organic variety. The corner classification imposes a guarantee that every configuration has a valid fill. WFC imposes local coherence. The result is a town that looks authored, from input that is barely more than a few dozen clicks. Lessons for infinite cities Several practical lessons follow from these systems. Confine the solver. WFC's non-locality is both its strength and its danger. Use local, hash-based rules to set boundaries, and let WFC work only inside them. Block modification and pre-collapsed edges are two ways to do this. Guarantee a fallback. Design the module set so that there is always a valid, if plain, solution: an all-ground tile, a basic wall for every corner configuration. Contradictions then become a matter of reduced variety rather than failure. Let structure come from above. Districts, roads, and lots should come from techniques designed for those scales: noise and Voronoi regions, L-system or tensor-field road generation, recursive lot subdivision. Ask WFC to fill regions, not to invent city plans. Decide early whether determinism matters. If seeds are shared or chunks are discarded and regenerated, chunk boundaries must be fixed by local rules. If the world is persistent and private, order-dependent generation is acceptable and gives the solver more freedom. Treat the grid as a design choice. Square grids are convenient but read as artificial. Stålberg's irregular quad grid shows that the topology a solver operates on is itself a tool for imposing character. What remains is the question every generator eventually faces: how to tell whether any of this output is good. A city generator can produce a billion distinct towns. Whether players experience them as a billion different places, or as one place shuffled, is a different question, and the subject of the final chapter. Chapter 10: Testing, Evaluating, and Controlling Generators The game designer and researcher Kate Compton gave the central problem of procedural generation a memorable name. In a widely read 2016 essay, "So you want to build a generator", she described it as the "10,000 bowls of oatmeal" problem. A generator can easily produce ten thousand bowls of oatmeal, each with every oat in a different position and orientation, each mathematically distinct from every other. Nobody will experience them as ten thousand different things. They are all just oatmeal. What matters is not whether outputs differ but whether they are perceived as different, in ways players care about. No Man's Sky encountered this at scale. Its eighteen quintillion planets were genuinely distinct as data. But at launch in 2016, many players reported that after visiting a few dozen planets, they had seen the range: the same kinds of terrain, the same kinds of creatures assembled from the same kinds of parts, recombined. The seed space was astronomically large; the space of perceptibly different experiences was much smaller. The studio's long run of free updates afterwards added new terrain types, biomes, and planetary features, enlarging the space of what the generator could express rather than the number of seeds. This chapter is about how to know whether a generator is good, and how to steer it when it is not. It covers the vocabulary for describing generators, expressive range analysis, automated testing for playability, search-based generation, determinism and performance testing, and the human tools that keep a designer in control. A vocabulary for generators Before evaluating a generator, it helps to describe it precisely. In 2011, Julian Togelius, Georgios Yannakakis, Kenneth Stanley, and Cameron Browne published "Search-Based Procedural Content Generation: A Taxonomy and Survey" in IEEE Transactions on Computational Intelligence and AI in Games. Its taxonomy, later expanded in the textbook Procedural Content Generation in Games by Noor Shaker, Julian Togelius, and Mark J. Nelson, distinguishes generators along several axes. Four are especially useful in practice. Online versus offline. An online generator runs during play, as the player explores; an offline generator runs during development or at load time. Online generators face strict time budgets and must be robust, because no human checks their output before players see it. Necessary versus optional content. Necessary content must be correct for the game to work: the level the player must complete. Optional content can fail gracefully: a decorative tree that looks a bit odd. Necessary content demands guarantees; optional content can accept occasional bad results. Constructive versus generate-and-test. A constructive generator produces output in one pass and guarantees its properties by construction, as Spelunky's solution path does. A generate-and-test generator produces candidates and checks them, discarding failures, as the cellular automaton cave generator that regenerates maps whose largest region is too small does. Degree of control. Some generators take only a seed. Others take parameters, such as difficulty, density, or style, that let a designer or the game steer the output. Table 6 places the algorithm families from this booklet against these properties. Table 6. Characteristics of the generator families covered in this booklet. Family Locality Guarantees Authoring input Typical failure Noise (Ch. 2-3) Fully local None by itself Parameters, curves Blandness, sameness Cellular automata (Ch. 4) Local, iterative None by itself Rule, density Disconnected regions Templates (Ch. 5) Structure-first Strong, constructive Hand-made rooms Recognisable repetition L-systems (Ch. 6) Per object Structural validity Grammar rules Textbook look, no context Placement (Ch. 7) Local with margins Spacing Rules over fields Uniformity, clumping WFC (Ch. 8-9) Non-local Local consistency Sample or tile set Contradictions, no global plan Expressive range The most useful single technique for understanding a generator is expressive range analysis, introduced by Gillian Smith and Jim Whitehead in a 2010 paper, "Analyzing the Expressive Range of a Level Generator". The idea is simple. Generate a large number of outputs, say several thousand. Measure each with a small number of metrics that capture properties designers care about. Plot the results as a two-dimensional histogram, with one metric on each axis. The plot shows where in the space of possible outputs the generator actually lands. Smith and Whitehead applied this to a platformer level generator using two metrics: linearity, how closely the level's profile follows a straight line, and leniency, a measure of how forgiving the level is, computed from the hazards and gaps it contains. Their histograms revealed things that playing a few levels would not: regions of the space the generator never reached, a strong bias toward particular kinds of level, and the way changes to generator parameters shifted the distribution. Expressive range analysis turns vague concerns into measurable ones. "The caves all feel the same" becomes "ninety percent of caves fall in a narrow band of open-area ratio and path length". A parameter change that seemed to make caves more varied can be checked: did the distribution actually widen, or did it just move? The metrics should be chosen per game. For terrain, they might be the fraction of land above a height, the number of distinct mountain ranges, and the length of coastline per unit area. For a city, the fraction of road area, the mean block size, and the number of distinct building types. For a level, path length, number of branches, and hazard density. Two cautions apply. First, metrics measure what is easy to compute, not necessarily what players perceive. A generator can show a wide expressive range in its metrics and still produce outputs that feel the same, because the variation is in properties players do not notice. Compton's oatmeal is the warning here. Second, expressive range describes the distribution of outputs, not the quality of any individual output. A generator can have a beautiful, wide distribution in which most outputs are mediocre. Pair range analysis with direct inspection of samples from across the distribution, especially the extremes, where the worst outputs live. Perceptual differentiation If metrics are not enough, what makes outputs feel different? Compton's essay and much subsequent practice point to a few principles. Variation should be in salient features. Players notice large-scale structure, silhouettes, colours, and things they interact with. They do not notice exact positions of small details. Variation spent on the positions of grass tufts is wasted; variation spent on whether a valley has a river, a ruin, or a cliff is noticed. Distinctiveness requires rarity. A feature that appears everywhere becomes background. Rare features, a giant arch, a crashed ship, a unique tree, become landmarks and make places memorable. Generators benefit from deliberately rare, high-impact elements alongside common ones. Context creates meaning. A ruin in the middle of a featureless plain is a random object. The same ruin at the end of a road, overlooking a river, with a broken bridge nearby, suggests a story. Generators that relate features to each other, placing them according to terrain and to other features, produce more perceived variety than generators that scatter features independently. This is the layered pipeline principle from Chapter 1 applied to meaning rather than geometry. Authored content multiplies procedural content. A small number of hand-made set pieces, combined with procedural surroundings, often produces more perceived variety than a larger amount of purely procedural content. The Spelunky model from Chapter 5 is an instance. Testing for playability For necessary content, the generator must not produce unplayable output. Constructive guarantees, as in Spelunky, are the strongest approach. When they are not available, automated testing fills the gap. Reachability checks. For any level where the player moves on a grid, a flood fill or breadth-first search verifies that the exit and all required items are reachable from the start. For platformers, reachability must account for movement physics: the search operates over states that include position and velocity or uses a precomputed table of which tiles can reach which other tiles by a jump. Agent playthroughs. A more thorough check is to have an artificial agent play the level. The Mario AI benchmark, built by Julian Togelius, Sergey Karakovskiy, and Robin Baumgarten around 2009 and 2010 on a clone of Super Mario Bros., became a standard testbed for this kind of work; an agent based on A* search that Baumgarten entered in the associated competition played levels almost perfectly by simulating the game's physics forward. Generators can use such agents to reject levels the agent cannot finish, or to estimate difficulty from how close the agent comes to failing. Constraint checking. Some properties are easier to verify than to guarantee: a minimum number of resources within a radius of the spawn, no biome smaller than some area, no structure placed on a steep slope. These become assertions that run on every generated output during testing and, in some cases, during play, with regeneration on failure. Generate-and-test budgets. Rejection is only practical if failure is rare. If one map in a hundred fails, regenerating is invisible. If half fail, generation time doubles on average and occasionally balloons. Track the failure rate as a metric. A rising rate is usually a sign that a recent change has made the generator's constraints harder to satisfy. Search-based generation Generate-and-test can go further than rejection. In search-based procedural content generation, a search algorithm, often an evolutionary algorithm, explores the space of generator parameters or content representations, guided by an evaluation function that scores each candidate. The survey by Togelius and colleagues defined the approach and catalogued examples: evolved racing tracks scored by how well they suited a player's driving style, evolved strategy-game maps scored for balance between players, evolved level layouts scored by agent playthroughs. Search-based generation is powerful when the evaluation function captures what matters and when evaluation is cheap enough to run thousands of times. It is usually too slow for online generation of large content but well suited to offline generation, to tuning generator parameters, and to generating a curated set of maps or levels that ship with the game. A variant that has grown in research use is quality-diversity search, such as the MAP-Elites algorithm by Jean-Baptiste Mouret and Jeff Clune, which keeps the best candidate in each cell of a grid defined by behavioural metrics. It is, in effect, an algorithm for filling an expressive range chart with good examples, which makes it a natural fit for content generation. Mixed-initiative and designer control Designers rarely want a generator that runs without them. The most successful production generators are tools that a designer steers. Seeds as content. Browsing seeds and picking good ones is a legitimate design technique. Many games ship with curated seeds for tutorials, daily challenges, or particular experiences, with the procedural system providing the variety and the designer providing the selection. Painted overrides. As in Horizon Zero Dawn's placement system from Chapter 7, designers paint masks that bias or override procedural rules. The generator handles the bulk; the designer handles the places that matter. Constraints as input. WFC and other constraint-based methods allow designers to pre-collapse cells: fixing a road here, a landmark there, and letting the solver fill in the rest consistently. Townscaper is an extreme case, where the player's entire interaction is placing constraints. Mixed-initiative design tools. Research tools such as Tanagra, a platformer level design tool by Gillian Smith, Jim Whitehead, and Michael Mateas published in 2010, let a designer and a generator edit a level together, with the designer placing elements and the generator, a constraint solver, filling in the rest while maintaining playability. The idea has been influential in tools that suggest completions or variations while the designer works. Determinism and performance testing Two kinds of testing are specific to generators and frequently neglected. Determinism tests. Store a set of "golden" seeds and the hashes of their outputs: the heightmap of a few chunks, the layout of a few levels. Run the generator on those seeds in continuous integration and compare. Any change in output is flagged. Some changes are intentional, in which case the golden hashes are updated deliberately; many are accidental, from a change in random call order, a different iteration order of a container, or a floating-point difference between platforms. Run the same tests on every target platform. A generator that produces different worlds on different consoles will cause bugs in any feature that shares seeds. Performance budgets. Online generators must keep ahead of the player. For a chunked world, that means generating chunks faster than the player can move into new ones, with enough margin for the worst case, such as a player in a fast vehicle or teleporting. Measure generation time per chunk across many seeds and attend to the tail, not the mean: a generator with occasional slow chunks, perhaps from WFC backtracking or generate-and-test rejection, produces hitches even if its average speed is fine. Moving generation to background threads, which the hash-based determinism of Chapter 1 makes safe, and generating at multiple levels of detail, coarse far away and fine nearby, are the standard techniques. Machine learning and the generator A body of research, surveyed by Adam Summerville and colleagues in a 2018 paper titled "Procedural Content Generation via Machine Learning", explores training models on existing content and sampling new content from them: levels learned from a corpus of existing levels, for instance. More recently, large generative models for images, text, three-dimensional assets, and even interactive video have advanced quickly, and research systems have demonstrated playable environments generated frame by frame by a neural network. These developments are real, but they do not displace the algorithms in this booklet for most game uses, for reasons the booklet's argument predicts. A game generator must honour the determinism contract, run within strict budgets, offer guarantees for necessary content, and give designers precise control. Learned models are, so far, weak at all four: their output is hard to make exactly reproducible across platforms, their cost is high, their guarantees are statistical rather than structural, and their controls are indirect. Where learned models are already useful is in the authoring stage: producing textures, variations of hand-made assets, or example inputs for algorithms like WFC, which then provide the guarantees. The pattern is familiar. A learned model is another source of variety; the structure that makes the output usable in a game still has to come from somewhere. What good looks like Putting this chapter together, a generator in good health has: • a clear statement of which content is necessary and what guarantees it must satisfy, with those guarantees provided by construction wherever possible; • automated checks for every guarantee that is not constructive, with failure rates tracked; • expressive range charts on a handful of metrics that designers agree matter, reviewed when the generator changes; • regular human inspection of samples from across the range, including the extremes; • golden-seed determinism tests on every platform; • per-chunk or per-level timing with attention to the tail; • and controls that let designers fix the places that matter without abandoning the procedural system everywhere else. None of these is glamorous. All of them are the difference between a generator that delights players for years and one whose output they learn to see through in an afternoon. Hashtags: #ProceduralGenerationInGames #ProceduralGeneration #ProceduralContentGeneration #PCG #GameDevelopment #GameDesign #GameProgramming #GameAlgorithms #EndlessWorlds #InfiniteWorldGeneration #ProceduralWorlds #ProceduralWorldBuilding #RandomWorldGeneration #SeedBasedGeneration #DeterministicGeneration #RandomNumberGeneration #PseudorandomNumberGenerators #HashBasedRandomness #ChunkBasedGeneration #WorldStreaming #TerrainGeneration #ProceduralTerrain #HeightmapGeneration #PerlinNoise #SimplexNoise #OpenSimplex #WorleyNoise #ValueNoise #GradientNoise #FractalBrownianMotion #FBM #DomainWarping #MultifractalNoise #NoiseFunctions #BiomeGeneration #ClimateBasedBiomes #HydraulicErosion #ThermalErosion #VoxelTerrain #VoxelWorlds #CellularAutomata #ProceduralCaves #CaveGeneration #DungeonGeneration #RoguelikeDevelopment #ProceduralLevelDesign #LevelGeneration #PlayableLevelGeneration #LSystems #LindenmayerSystems #ProceduralVegetation #ProceduralTrees #SpaceColonizationAlgorithm #PoissonDiskSampling #WaveFunctionCollapse #WFCAlgorithm #ConstraintPropagation #ConstraintSatisfaction #TileBasedGeneration #ProceduralCities #ProceduralArchitecture #ProceduralModeling #ProceduralContentDesign #ProceduralAlgorithms #GameWorldOptimization #AutomatedPlaytesting #ExpressiveRangeAnalysis #SearchBasedGeneration #MinecraftWorldGeneration #NoMansSky #Spelunky #Townscaper #BadNorth #CreativeCoding #GenerativeDesign

Download the Book(PDF): Introduction In May 2023 a federal judge in New York was handed a legal brief that cited half a dozen court decisions which did not exist. The cases had names, docket numbers, quoted passages and plausible reasoning. They had been produced by a large language model that one of the lawyers had used for research, and when he asked the same system whether the cases were real, it assured him that they were. The lawyers were sanctioned, and the episode, Mata v. Avianca, became the standard anecdote for a phenomenon the field had already named: hallucination. A few months later a tribunal in British Columbia ordered Air Canada to honour a bereavement-fare policy that its customer-service chatbot had invented. The airline argued, without success, that the chatbot was responsible for its own statements. Neither case was a disaster. Nobody died; a few thousand dollars changed hands. But they illustrate with unusual clarity a problem that becomes very serious when the same technology moves from drafting briefs to recommending drug doses, interpreting radiology scans, steering vehicles or approving financial transactions. A neural network is a machine for producing plausible outputs. Plausibility and truth usually coincide, which is why these systems are so useful. When they diverge, the system has no internal means of noticing. It produces the false answer with the same fluency, and often the same expressed confidence, as the true one. This booklet is about the most serious engineering response to that problem: the deliberate combination of neural networks with formal, symbolic methods — logic, ontologies, rule engines, constraint solvers and mathematical verification. The field goes by the name neuro-symbolic AI, and it is older than the current wave of interest suggests. Researchers have tried to unify learning and reasoning since the 1980s. What has changed is the stakes. Neural systems are now capable enough that people want to use them everywhere, including places where an error has consequences that cannot be undone, and they remain unreliable in a way that no amount of further training has eliminated. The argument The controlling claim of this booklet is simple to state and has demanding consequences. Hallucination is not a defect that will be trained out of neural networks; it is a structural consequence of what predictive models are. A model that learns a probability distribution over plausible outputs will sometimes assign high probability to false ones, and it has no access to a criterion of truth separate from the statistics it learned. The remedy in safety-critical settings, therefore, is not to make the neural network more trustworthy on its own. It is to build systems in which the neural network proposes and a symbolic component, with explicit semantics and checkable guarantees, decides what may be asserted or done. Authority over the final output must sit with something whose behaviour can be stated in advance and verified. Put more briefly: the network supplies perception, intuition and breadth; logic supplies accountability. The craft of neuro-symbolic engineering is in drawing the boundary between them — deciding what the symbolic layer checks, what it can check, how it reports failure, and what happens when the check cannot be completed. This position sits between two familiar camps. One holds that scale will solve everything: larger models trained on more data with better feedback will become reliable enough that external checks are unnecessary. The other holds that neural networks are fundamentally the wrong tool and that real intelligence requires explicit symbolic reasoning from the ground up. The argument here concedes much to both. Scale has indeed delivered capabilities that symbolic AI never approached in sixty years of trying, and the frontier models of 2025 and 2026 reason far better than anyone predicted. Yet the guarantee problem is not a capability problem. A system that is right 99.9 percent of the time and cannot tell you which 0.1 percent it is wrong about is a different kind of object from a system that is right 95 percent of the time and refuses to answer the other 5. For an insulin pump, an aircraft collision-avoidance system or a sanctions screening process, the second is often the one you want. What the booklet covers The first chapter makes the case that hallucination is structural, drawing on both the theoretical results that now show calibrated predictors must sometimes generate falsehoods and the practical experience of deploying them. The second recounts the long rivalry between symbolic and connectionist AI, because the failure modes of each tradition explain why neither can stand alone, and because the history is too often forgotten by people rediscovering its lessons. The third chapter explains the symbolic machinery itself — propositional and first-order logic, description logics, Datalog, satisfiability and SMT solving, answer set programming, and interactive theorem provers — with attention to the trade between what a formalism can express and what a machine can decide about it. The fourth surveys the architectures by which neural and symbolic components are joined, from loose pipelines to systems in which logic is compiled into the network's training objective. The middle chapters examine three distinct ways symbolic methods discipline neural ones. Ontologies and knowledge graphs give neural outputs something to be checked against: a curated, structured account of what exists and how it relates. Deductive engines and proof checkers verify reasoning chains, so that a model's argument is accepted only when a machine can confirm each step. Formal verification of neural networks themselves proves properties of the network's input–output behaviour across whole regions of input space rather than at sampled test points. The next chapters move from techniques to deployment. One examines runtime assurance — the architectures, such as the Simplex pattern and safety shields, that allow an unverified learned controller to operate inside a verified safety envelope — and the certification frameworks emerging in aviation and automotive engineering. Another works through cases in medicine, law, finance and cloud security, where symbolic checks on neural outputs are already in production. A further chapter takes the objections seriously: the specification bottleneck, the cost of building and maintaining knowledge bases, the danger that a verified component lends false confidence to an unverified system, and the cases where neural methods have simply outperformed symbolic ones. The final chapter turns all of this into a design discipline for people who must build such systems. Who this is for The booklet is written for readers who need to make decisions about AI in consequential settings — engineers, technical leaders, safety and compliance professionals, regulators, clinicians and lawyers who work alongside these systems, and students who want to understand where the field is heading. It assumes no training in formal logic or machine learning. Technical terms are defined when they first appear, and a glossary collects the ones that recur. It is not a programming manual, and it does not survey every neuro-symbolic research system published in the last five years; there are hundreds, and most will not survive. The aim is to give the reader a durable way of thinking about the problem: where guarantees can come from, what they cost, and how to tell a system that is actually safe from one that merely contains a component with the word "verified" in its description. One caution at the outset. The phrase "neuro-symbolic" has become fashionable, and fashionable terms attract loose use. A chatbot that calls a calculator is, in some technical sense, neuro-symbolic. So is a large language model that writes code which is then executed. Some of these combinations deliver real guarantees; many deliver none. The test that runs through this booklet is a hard one: after the symbolic component has done its work, what can you now say about the system's output that you could not say before, and can you prove it? If the answer is nothing, the integration is decoration. Chapter 1. Why Prediction Is Not Knowledge The word "hallucination" is a poor metaphor. It suggests a malfunction — a healthy system temporarily disturbed, seeing things that are not there. That framing invites the hope that the disturbance can be cured. A better account starts from what a neural network is actually built to do, and shows that confident falsehood is a natural output of that design rather than a departure from it. What a neural network learns A neural network is a parameterised function. Given an input — an image, a sequence of words, a vector of sensor readings — it computes an output through many layers of weighted sums and simple nonlinear operations. Training adjusts the weights, often billions of them, so that the outputs on a large set of examples come close to the desired ones. For a classifier, the desired output is a label. For a language model, it is the next token of text, and the network produces a probability distribution over every token in its vocabulary. The objective that drives a language model's training is to assign high probability to the text that actually appears in its training corpus. Nothing in that objective refers to truth. The corpus contains true statements, false statements, fiction, jokes, outdated facts, mistaken arguments and contradictory claims. The model learns to reproduce the patterns of all of it. Later stages of training — instruction tuning, reinforcement learning from human feedback, and their successors — shift the distribution toward answers that people rate as helpful and correct, and this helps a great deal. But the raters judge outputs they can evaluate, and the reward models trained on their judgements are themselves neural networks with the same limitation. The machinery remains a machine for producing what is likely given what came before. Most of the time, likely and true coincide, because the world the corpus describes is mostly described accurately and because a statement's truth correlates with how often and how consistently it is repeated. Paris is the capital of France in millions of documents. The boiling point of water at sea level is stated the same way everywhere. A model that has absorbed these patterns will reproduce them reliably. The difficulty arises in the long tail. Consider a question about an obscure court case, a rare drug interaction, a minor historical figure or the specific clause of a specific contract. The training data may contain the fact once, or not at all. The model's representation of it is weak. But the model has a very strong representation of what an answer to that kind of question looks like. Legal citations have a format: party names, a reporter volume, a page number, a court and a year. Drug interaction warnings have a register and a structure. When the specific knowledge is missing, the general form remains, and the model fills it with plausible content. The result is the fake case in Mata v. Avianca: correctly formatted, stylistically perfect, and false. Why it cannot simply be trained away Several lines of theoretical work have now converged on the conclusion that this behaviour is not an accident of current training methods. The first is a statistical argument. In 2024 Adam Kalai and Santosh Vempala showed that a language model which is well calibrated — one whose stated probabilities match observed frequencies — must generate false statements at a rate tied to the fraction of facts that appear only once in its training data. The intuition runs as follows. For a fact seen exactly once, the model cannot distinguish it from the countless similar-looking facts that were never seen but might have been. If it is calibrated, it must spread probability across all of them, and when it samples, it will sometimes produce one of the unseen, false variants. Arbitrary facts of this kind — birthdays, citation numbers, the names of minor officials — are exactly the ones on which hallucination is most common. A follow-up analysis published by researchers at OpenAI in 2025 extended the argument and added a second cause: the evaluation benchmarks used to rank models typically reward a guess over an admission of uncertainty, because a guess sometimes scores and "I don't know" never does. Models are therefore pushed, by the incentive structure of their own evaluation, to bluff. The second is a computability argument. Researchers have pointed out that if one defines a hallucination as any output that differs from a ground-truth function, then no computable model can avoid hallucinating on all inputs for all ground-truth functions, by a diagonal construction similar to the classic results of Turing and Gödel. This is a formal result with limited direct practical bite — it says something about worst cases over all possible worlds — but it does establish that "a model that never hallucinates" is not an engineering target that more data could reach. The third is the most practically important, and it does not need a theorem. A neural network's confidence is learned the same way its answers are, and so it is subject to the same failure. A model can be trained to express uncertainty, and frontier models do this considerably better than their predecessors. But the expression of uncertainty is itself an output generated by pattern, and the model can be confidently wrong about how confident it should be. There is no separate, privileged channel through which the network inspects its own knowledge and reports honestly on its gaps. What looks like self-knowledge is a further prediction. None of this means that the rate of hallucination cannot be reduced. It has been reduced, substantially, by retrieval of source documents, by training models to abstain, by better feedback, and by giving models time to reason before answering. Frontier systems in 2026 make far fewer factual errors on common questions than systems of 2022. The claim is narrower and more important: the rate cannot be driven to zero, and — this is the crux — the residual errors are not flagged. They arrive in the same voice as the correct answers. Beyond language: the same structure in perception and control The term "hallucination" belongs to language models, but the underlying problem is general to learned systems. An image classifier trained to recognise pedestrians learns a statistical association between pixel patterns and a label. Inside its training distribution, it may be extremely accurate. Outside it — at night, in fog, with an unusual costume, with a person pushing a bicycle across a road where pedestrians are not expected — its outputs can be wrong with high confidence. The 2018 fatal crash of an Uber test vehicle in Tempe, Arizona, is often cited here. The investigation by the US National Transportation Safety Board found that the perception system had repeatedly reclassified a woman walking a bicycle — as an unknown object, a vehicle, a bicycle — and that each reclassification discarded the history needed to predict her path. That was a failure of system design as much as of the network, which is precisely the point: the network's output was treated as a fact by the downstream logic, with nothing to check whether the sequence of outputs made physical sense. Adversarial examples make the same point in its most extreme form. Since the work of Christian Szegedy and colleagues in 2013, it has been known that imperceptible perturbations to an image can change a network's classification arbitrarily. A stop sign with a few strategically placed stickers can be read as a speed-limit sign. The network is not malfunctioning; it is computing exactly the function it learned. That function simply has properties that nobody specified and nobody checked. In learned control — a reinforcement-learning policy for a robot or a drone — the analogue is a policy that behaves well in the states it was trained on and takes an arbitrary action in states it never saw. If those states are near the edge of a safety envelope, an arbitrary action may be a catastrophic one. Across all three settings, the common structure is this: the learned system produces an output that is plausible relative to its training, there is no internal criterion by which it can distinguish correct from incorrect outputs in unfamiliar territory, and the cost of error is borne by whatever acts on the output. The missing ingredient: semantics What would it mean for a system to know rather than predict? Philosophers have argued about the definition of knowledge for two and a half thousand years, and this booklet will not settle it. But engineering needs only a working version, and the working version is this: a system's output counts as knowledge, for practical purposes, when there is an independent, inspectable reason to accept it — a reason that can be stated, checked by someone other than the system itself, and that would have prevented the output had the output been false. Symbolic systems are built around exactly such reasons. A theorem prover outputs a theorem together with a proof, and the proof can be checked by a small, independently verifiable program. A rule engine that denies a loan can say which rule fired and which facts triggered it. A database query returns rows that satisfy a precisely defined condition, and anyone can verify that each returned row satisfies it. A type checker that accepts a program guarantees that certain errors cannot occur when it runs. In each case the output is accompanied by, or derivable from, a justification whose meaning is fixed independently of the system that produced it. That is what "semantics" means in this context: the symbols have a meaning defined outside the machine, and the machine's operations are guaranteed to respect it. A neural network's internal representations have no such externally fixed meaning. The activations inside a language model correlate with concepts — interpretability research has found features that respond to particular entities, topics or properties — but these correlations are discovered after the fact, they are approximate, and nothing guarantees that the network's computation respects them. When the network says that a drug is safe at a given dose, there is no proposition inside it, with defined truth conditions, that was evaluated and found true. This is the deep reason hybrid systems are attractive. They do not ask the neural network to acquire semantics it lacks. They pair it with components that have semantics by construction and arrange the system so that what matters is checked by those components. What counts as a remedy It helps to be precise about the kinds of failure a symbolic layer can address, because they differ, and the right tool differs with them. The first kind is factual error: the system asserts something about the world that is false. The symbolic remedy is grounding — checking the assertion against a curated, structured source such as a knowledge graph, ontology or authoritative database, and refusing or flagging assertions that the source does not support. The second kind is reasoning error: the system's premises may be correct, but the conclusion does not follow from them. Language models make arithmetic slips, invert conditionals, mishandle negation and quantifiers, and lose track of constraints across long chains of inference. The symbolic remedy is to move the reasoning into a formal system — translate the problem into logic or code, solve it with a sound engine, and translate back — or to require that the model's reasoning be expressed in a form that a checker can verify step by step. The third kind is constraint violation: the output may be individually plausible but violates a rule the system is bound by — a regulatory requirement, a physical limit, an organisational policy, a type or format. The symbolic remedy is to encode the constraints explicitly and enforce them, either by filtering outputs after generation or by restricting generation so that violating outputs cannot be produced at all. The fourth kind is behavioural unsafety: a learned controller takes an action that leads, or could lead, to harm. The symbolic remedy is runtime assurance — a verified monitor that can override the learned controller — or formal verification of the controller itself over the relevant region of its input space. The fifth kind is the hardest and is often confused with the others: specification error. The system does exactly what it was told, and what it was told was wrong or incomplete. No symbolic method fixes this by itself. A verified system faithfully implements its specification, including the specification's mistakes. This category will return later in the booklet, because it marks the boundary of what neuro-symbolic integration can promise. Table 1 sets out these five failure types against their symbolic remedies and the strength of guarantee each remedy can offer. Table 1. Failure types in neural systems and their symbolic remedies. Failure type Typical example Symbolic remedy Strength of guarantee Factual error Invented citation or drug fact Check against knowledge graph, ontology or database As good as the curated source's coverage Reasoning error Arithmetic slip, invalid inference Translate to logic or code; solve or verify formally Sound if the translation is correct Constraint violation Output breaches policy or format Explicit rules enforced by filter or constrained generation Complete for the rules that were encoded Behavioural unsafety Learned controller leaves safe envelope Runtime monitor with verified fallback; network verification Provable within the model's assumptions Specification error System faithfully implements a wrong rule None internally; requires human review of the specification None The right-hand column is the honest part of the table. Each guarantee is conditional. Grounding is only as good as the knowledge base. Formal reasoning is only as good as the translation from natural language into logic, which is itself frequently performed by a neural network. Constraint enforcement covers only the constraints someone thought to write down. Runtime assurance holds only under the assumptions of its physical model. The conditional nature of these guarantees is not a reason to dismiss them. It is a reason to understand them precisely — and to see that their great virtue is that the conditions are stated. A neural network's reliability is conditioned on things nobody can enumerate. A symbolic guarantee is conditioned on things that can be written down, reviewed, contested and tested. The shape of the solution From this analysis a design principle follows, and the rest of the booklet elaborates it. In a system where errors matter, the neural component should be treated as a generator of candidates, and the authority to commit — to assert a fact to a user, to execute an action, to approve a transaction — should belong to a component whose acceptance criteria are explicit and checkable. This principle is easy to state and easy to violate. Systems are routinely built in which a symbolic component is present but subordinate: a rule-based filter that the neural output can bypass, a knowledge graph that the model is "encouraged" to consult, a verification step that runs only when the model chooses to call it. In such systems, the guarantee is only as strong as the neural network's willingness to submit to it, which is to say, no guarantee at all. The principle also has a cost. Every time the symbolic layer rejects a candidate, the system must do something — ask the network to try again, fall back to a conservative default, escalate to a human, or decline to answer. Systems designed this way are less fluent, less accommodating and sometimes less helpful than unconstrained neural systems. In safety-critical settings, that trade is usually worth making. The rest of this booklet is about how to make it well. Chapter 2. Two Traditions and Their Failures Artificial intelligence has been divided since its founding between two ideas of what intelligence is. One holds that thinking is the manipulation of symbols according to rules. The other holds that it is the adjustment of connections in a network until the network's responses fit the world. Each has had periods of dominance, each has produced real achievements, and each has failed in ways that are instructive. The case for integration rests on understanding those failures, because they turn out to be complementary: what one tradition cannot do is what the other does best. The symbolic programme The 1956 Dartmouth workshop that gave the field its name was organised around the conjecture that every aspect of intelligence could be described precisely enough for a machine to simulate it. The most influential early systems took "described precisely" to mean "expressed in logic". Allen Newell, Herbert Simon and Cliff Shaw's Logic Theorist, demonstrated in the same year, proved theorems from Whitehead and Russell's Principia Mathematica by searching through possible applications of inference rules. Newell and Simon's later physical symbol system hypothesis made the ambition explicit: a system that manipulates symbols according to rules has the necessary and sufficient means for general intelligent action. For three decades this programme defined the field. It produced theorem provers, planners, natural-language systems for restricted domains and, most commercially, expert systems. An expert system encoded a specialist's knowledge as a large collection of if–then rules and used an inference engine to chain them together. MYCIN, developed at Stanford in the 1970s, diagnosed bacterial blood infections and recommended antibiotics using several hundred rules with attached certainty factors; in a blinded evaluation, its recommendations were judged at least as acceptable as those of infectious-disease specialists. XCON, built for Digital Equipment Corporation, configured VAX computer orders and was credited with saving the company substantial sums annually through the 1980s. By the middle of that decade, expert systems were a significant industry. The strengths of these systems are exactly the properties that neural networks lack. Their knowledge was explicit: anyone could read the rules. Their reasoning was traceable: MYCIN could answer "why?" by showing which rule it was trying to establish and "how?" by showing the chain that led to a conclusion. Their behaviour was predictable in the sense that a given set of facts always produced the same conclusions, and an engineer could examine the rule base to see what the system would do in a given situation. When they were wrong, the error could be located in a specific rule and fixed. The failures were equally clear, and they came to be summarised under a few headings. The first was the knowledge acquisition bottleneck. Every rule had to be elicited from a human expert, formalised by a knowledge engineer and tested. Experts often could not articulate what they knew; much expert skill is tacit, recognitional, the product of experience rather than explicit principle. Building a rule base was slow and expensive, and the cost grew faster than linearly with the size of the domain, because each new rule could interact with all the existing ones. The second was brittleness. Expert systems performed well inside the narrow domain their rules covered and failed abruptly outside it. They had no common sense. A medical system might know a great deal about blood infections and nothing about the fact that patients are people who can be pregnant, allergic, elderly or lying. A system that encounters a situation its rules did not anticipate does not degrade gracefully; it either produces nonsense or produces nothing. The third was the grounding problem. Symbols in a rule base mean something only because a human interprets them. The rule "if the organism is gram-negative and rod-shaped, then..." presupposes that someone has looked through a microscope and correctly determined that the organism is gram-negative and rod-shaped. The system cannot see, hear or touch. Stevan Harnad named this the symbol grounding problem in 1990: how can the symbols in a formal system acquire meaning that is intrinsic to the system rather than parasitic on the meanings in a human head? For practical expert systems, the answer was that they could not, and so every input had to be prepared by a person. The most ambitious attempt to overcome brittleness was Cyc, started by Douglas Lenat in 1984 with the aim of hand-encoding the common-sense knowledge that expert systems lacked. Over four decades the project accumulated millions of assertions in a rich logical language. It is a remarkable artefact and has been used in commercial applications, but it did not deliver general common sense, and its history is often read as evidence that the knowledge acquisition bottleneck cannot be overcome by effort alone. The world contains too much, and too much of it is graded, contextual and exception-laden, for exhaustive manual formalisation. By the late 1980s, expert systems had disappointed their commercial backers, and funding collapsed in what became known as the second AI winter. The symbolic tradition did not die — it continued in automated reasoning, formal methods, planning, the semantic web and database theory, where it produced tools of enormous practical value — but it ceased to be the dominant idea of what AI was. The connectionist programme The alternative tradition began almost as early. Warren McCulloch and Walter Pitts described a mathematical model of neurons in 1943. Frank Rosenblatt built the perceptron, a trainable single-layer network, in 1958. Marvin Minsky and Seymour Papert's 1969 book Perceptrons demonstrated the limits of single-layer networks so effectively that the approach was largely abandoned for a decade. Its revival came with the popularisation of backpropagation for training multi-layer networks, in the 1986 paper by David Rumelhart, Geoffrey Hinton and Ronald Williams, and the parallel distributed processing movement that accompanied it. Connectionism's promise was the inverse of the symbolic programme's. Instead of a human writing down knowledge, the network would learn it from examples. Instead of discrete symbols with brittle boundaries, it would use continuous representations that could capture similarity, gradation and noise. Instead of failing abruptly outside its rules, it would generalise — produce reasonable responses to inputs it had never seen, by virtue of their resemblance to inputs it had. For two decades this promise was only partly kept. Networks worked on small problems but were hard to train at scale. The decisive turn came around 2012, when Alex Krizhevsky, Ilya Sutskever and Hinton trained a deep convolutional network on graphics processors and won the ImageNet image-recognition competition by a wide margin. The combination of large datasets, parallel hardware and a few technical refinements made deep networks practical, and they rapidly became the best available method for speech recognition, machine translation, image analysis and, eventually, language generation. The transformer architecture, introduced in 2017, made it feasible to train language models on a significant fraction of the text on the internet, and the large language models that followed now write, summarise, translate, code and answer questions at a level that would have been unimaginable to the expert-systems builders. In effect, deep learning solved the problems that had defeated symbolic AI. It dissolved the knowledge acquisition bottleneck: knowledge is absorbed from data rather than elicited from experts. It softened brittleness: a language model has something resembling common sense, absorbed from the vast range of human writing, and handles novel phrasings and unexpected topics gracefully. It largely solved perceptual grounding: networks can map raw pixels and audio to categories, which no symbolic system ever managed. But deep learning reintroduced, in new form, the problems that symbolic AI had solved. Its knowledge is implicit, distributed across billions of parameters and not readable by anyone. Its reasoning is not traceable; a network can be asked to explain itself, but the explanation is another generated output with no guaranteed relationship to the computation that produced the answer. Its behaviour is not predictable in the engineering sense: one cannot inspect a network and determine what it will do on a given class of inputs. And when it is wrong, there is no rule to fix. Retraining may correct one error while introducing others elsewhere. Deep networks also struggle with things that symbolic systems find trivial. They have difficulty with systematic compositional generalisation — applying a learned rule reliably to combinations not seen in training. They make arithmetic errors that a pocket calculator would not. They handle negation, quantifiers and long chains of dependent constraints unreliably. They can be led into inconsistency: asserting a claim and its negation in different contexts, or giving answers that violate constraints they correctly stated a few sentences earlier. The complementarity Laid side by side, the two traditions' strengths and weaknesses mirror each other almost exactly. Symbolic systems are precise, transparent, verifiable and compositional, but they are brittle, cannot perceive and are costly to build. Neural systems are flexible, perceptive, robust to noise and learn from data, but they are opaque, unverifiable, prone to confident error and weak at exact reasoning. The psychologist Daniel Kahneman's distinction between two modes of human thought, popularised in his 2011 book Thinking, Fast and Slow, has become the standard analogy. "System 1" is fast, automatic, associative and intuitive — recognising a face, reading a word, sensing that something is wrong. "System 2" is slow, deliberate, sequential and effortful — multiplying two large numbers, following a proof, checking a contract. Neural networks look like System 1; symbolic reasoning looks like System 2. Human expertise depends on both, and on their interaction: the intuition that suggests a diagnosis and the deliberate check that confirms or rejects it. The analogy should not be pushed too far. Human System 2 is implemented in the same neural tissue as System 1, and the most capable language models now perform extended step-by-step reasoning that looks very like deliberate thought. The analogy does not settle whether symbolic machinery must be explicit and separate. What it captures well is the functional point: reliable cognition needs both a fast generator of candidates and a slower process that checks them against explicit standards. The debate that would not end The question of whether neural networks need symbolic supplementation became a public dispute in the late 2010s, most visibly between the cognitive scientist Gary Marcus and the deep-learning pioneer Yoshua Bengio, who debated the question in Montreal in December 2019. Marcus argued that deep learning lacked the capacity for abstraction, compositionality and reliable reasoning, and that hybrid architectures with explicit symbolic components were necessary. Bengio agreed that current systems lacked these capacities but argued that they should be acquired by extending neural methods — through attention, modular architectures and new training objectives — rather than by bolting on hand-built symbolic machinery. The years since have given evidence to both sides. On Bengio's side, scaled language models acquired reasoning abilities that critics had said were out of reach; models trained with reinforcement learning to produce long chains of reasoning before answering now solve competition mathematics and programming problems at a high level. In July 2025, Google DeepMind reported that an advanced version of its Gemini model had achieved gold-medal-standard performance at the International Mathematical Olympiad working entirely in natural language, a year after its previous best result had relied on formal proof in the Lean theorem prover. That is a significant data point against the claim that explicit symbolic machinery is necessary for high-level reasoning. On Marcus's side, the same models continue to hallucinate, continue to make errors in simple reasoning under unfamiliar framings, and continue to offer no guarantees. And many of the most impressive results of the period were in fact hybrid. AlphaGo combined neural networks with Monte Carlo tree search. AlphaGeometry combined a language model with a symbolic deduction engine. AlphaProof used reinforcement learning against the Lean proof checker. Code-generating models are deployed with compilers, type checkers and test suites. The frontier systems themselves increasingly call tools — calculators, interpreters, search engines, databases — which are symbolic components in all but name. The resolution this booklet proposes is that the debate was partly about the wrong question. Whether a neural network can learn to reason well enough is an empirical question about capability, and the answer increasingly appears to be yes for many tasks. Whether a neural network's reasoning can be trusted without independent checking is a different question, about assurance, and the answer remains no. Even a model that reasons as well as a skilled human mathematician still needs its proofs checked, just as human mathematicians do. The value of the symbolic component in a safety-critical system is not that it reasons better than the network. It is that its reasoning can be verified. The third wave Researchers who work on integration have described their field as a third wave, following the symbolic first wave and the statistical second. Henry Kautz's 2020 Engelmore lecture to the Association for the Advancement of Artificial Intelligence, "The Third AI Summer", offered a taxonomy of integration styles that has become a standard reference and is examined in Chapter 4. Artur d'Avila Garcez and Luís Lamb, who have worked on neural-symbolic systems since the 1990s, have argued that integration is necessary for AI systems that are robust, explainable and capable of learning from small amounts of data. Research agencies have funded the area explicitly: the US Defense Advanced Research Projects Agency's Assured Neuro Symbolic Learning and Reasoning programme, launched in 2022, aims at hybrid systems whose trustworthiness can be demonstrated for safety-critical military use. The history matters for a practical reason. The failure modes of the first wave have not gone away; they reappear whenever a symbolic component is introduced into a modern system. A knowledge graph used to ground a language model faces the knowledge acquisition bottleneck. A rule engine that checks a model's outputs is brittle in exactly the way expert systems were. A formal specification is only as complete as the person who wrote it. Neuro-symbolic integration does not escape these problems. Its bet is that each tradition can be used where its weaknesses do least harm: neural networks where flexibility and perception matter and errors can be caught, symbolic methods where correctness matters and the domain can be formalised. Making that bet well requires knowing what the symbolic tools can actually do, which is the subject of the next chapter. Chapter 3. The Machinery of Logic "Symbolic AI" covers a family of formal tools that differ greatly in what they can express, what they can compute and what they guarantee. A designer who plans to use logic to discipline a neural network needs to choose among them, and the choice is governed by a trade-off that runs through the whole of the field: the more a formalism can say, the less a machine can decide about what has been said. This chapter explains that trade-off and the main tools on each side of it, without assuming any background in logic. What a logic is A logic has three parts. Its syntax defines which strings of symbols count as well-formed statements. Its semantics defines what those statements mean — usually by specifying, for any possible state of affairs, which statements are true in it. And its proof system defines rules for deriving new statements from old ones by purely mechanical manipulation of symbols. The two properties that matter most connect proof with meaning. A proof system is sound if everything it derives is actually true whenever the premises are true: it never proves a falsehood. It is complete if everything that is true whenever the premises are true can be derived: it never misses a valid conclusion. Soundness is the property that makes logic valuable as a check on neural outputs. If a sound engine says a conclusion follows from the premises, it does — not probably, not usually, but in every possible situation where the premises hold. A third property concerns computation. A question is decidable if there is an algorithm that always terminates with the correct yes-or-no answer. Some logics are decidable; for these, a machine can always determine whether a statement follows from a set of premises. Others are not; a machine can confirm that a statement follows when it does, but may search forever when it does not. And among decidable logics, the cost of deciding varies from trivially fast to astronomically slow. Propositional logic and satisfiability The simplest useful logic is propositional logic. Its atoms are statements that are simply true or false — "the valve is open", "the patient is allergic to penicillin" — combined with and, or, not and implies. Its central computational problem is satisfiability, usually called SAT: given a formula, is there an assignment of true and false to the atoms that makes it true? SAT was the first problem proved NP-complete, by Stephen Cook in 1971, which means that no known algorithm solves every instance efficiently and it is widely believed none exists. In practice, however, modern SAT solvers — built on a technique called conflict-driven clause learning, developed in the 1990s — routinely solve industrial instances with millions of variables. They are used to verify hardware designs, to check software configurations and to schedule resources. The gap between worst-case theory and practical performance is one of the major engineering success stories of computer science, and it matters for neuro-symbolic systems because it means that exact logical checks are often far cheaper in practice than complexity theory suggests. Propositional logic is expressively limited. It cannot talk about objects and their properties in general; it can only name specific facts. To say "every patient allergic to penicillin must not be prescribed amoxicillin", it would need a separate atom for every patient. First-order logic First-order logic adds variables, quantifiers ("for all", "there exists"), predicates that express properties and relations, and functions. It can state general rules: for every patient p and every drug d, if p is allergic to some ingredient of d, then d must not be prescribed to p. Most of mathematics can be formalised in first-order logic together with set theory, and it is the default language in which philosophers and computer scientists think about formal reasoning. First-order logic has a sound and complete proof system, as Kurt Gödel showed in 1929. But it is undecidable, as Alonzo Church and Alan Turing independently showed in 1936: there is no algorithm that determines, for every first-order statement, whether it follows from a given set of premises. Automated theorem provers for first-order logic — systems such as Vampire and E — search for proofs and are very effective at finding them when they exist, but cannot always report failure when they do not. Description logics and ontologies Description logics are fragments of first-order logic designed specifically to remain decidable while expressing the kind of knowledge found in taxonomies and ontologies. They talk about concepts (classes of things, such as "bacterial pneumonia"), roles (relations between things, such as "has causative agent") and individuals. A typical axiom says that every instance of one concept is an instance of another, or that every instance of a concept stands in some relation to an instance of a second concept: bacterial pneumonia is a pneumonia whose causative agent is some bacterium. The Web Ontology Language, OWL, standardised by the World Wide Web Consortium in 2004 and revised as OWL 2 in 2009, is based on a description logic. Its most expressive standard variant is decidable but computationally very expensive in the worst case. Recognising this, OWL 2 defined profiles — restricted sublanguages with better computational properties. The EL profile, for example, gives up some expressive features in exchange for reasoning in polynomial time, and it is expressive enough for very large biomedical terminologies. SNOMED CT, the clinical terminology used in electronic health records in many countries, contains several hundred thousand concepts and is built on logic of this kind; specialised reasoners can classify the entire terminology — compute every subclass relationship it implies — in seconds. Description logic reasoners can answer questions that are directly useful for checking neural outputs. Is this set of assertions consistent with the ontology? Is this individual an instance of this concept? Does this concept subsume that one? If a language model asserts that a particular organism causes a particular disease, and the ontology entails that the organism belongs to a class that cannot cause that disease, the reasoner detects the contradiction. Description logics and ontology languages typically adopt the open-world assumption: a fact that is not stated is unknown, not false. This is appropriate for knowledge on the web, where no source is complete, but it surprises engineers who expect database behaviour. An ontology that does not say a patient has diabetes does not entail that the patient does not have diabetes. Datalog and rule languages Datalog is a rule language derived from logic programming. A Datalog program consists of facts and rules of the form "if these conditions hold, then this conclusion holds", and its semantics is the smallest set of facts closed under the rules. It adopts the closed-world assumption: what cannot be derived is false. Datalog is decidable, and for a fixed program it can be evaluated in time polynomial in the size of the data, which makes it well suited to large datasets. It is used in program analysis, in network configuration checking, in access-control policy languages and in knowledge-graph reasoning. Production-rule systems, the descendants of the expert-system inference engines, remain in widespread commercial use as business rule engines. Systems such as Drools and commercial decision-management platforms encode eligibility rules, pricing rules, compliance checks and underwriting criteria. Their semantics is often more operational than logical — rules fire in an order determined by a conflict-resolution strategy — which makes them less amenable to formal analysis than Datalog, but they are well understood by business analysts and are frequently the place where an organisation's policies already live in executable form. SMT solving Satisfiability modulo theories, or SMT, extends SAT with built-in knowledge of specific mathematical domains: integer and real arithmetic, arrays, bit-vectors, strings and others. An SMT solver can answer questions such as "is there an integer assignment to these variables satisfying these linear inequalities and these logical conditions?" Microsoft Research's Z3, released in 2008, and the open-source cvc5 are the most widely used. SMT solvers are the workhorses of modern software verification. They are used to check that programs cannot overflow, that access-control policies grant only intended permissions, that compilers preserve program meaning and that hardware behaves according to its specification. For neuro-symbolic integration they are particularly important because many of the constraints one wants to impose on a neural output are arithmetic: a dose within a range, a sum that balances, a schedule with no overlaps, a payment that complies with a limit. SMT can check these exactly and, when a check fails, produce a concrete counterexample showing why. Answer set programming Answer set programming is a form of declarative programming suited to combinatorial search problems — configuration, planning, scheduling, diagnosis. The programmer states the problem as rules and constraints, including default rules ("normally, a bird flies, unless it is known to be a penguin"), and a solver such as clingo computes the answer sets: the stable models that satisfy all constraints. Its handling of defaults and exceptions makes it attractive for encoding regulations and policies, which are full of them, and several neuro-symbolic research systems use it as the reasoning layer for perception networks. Probabilistic logics Pure logic deals in certainties. Real data, and especially neural outputs, come with probabilities. A family of formalisms — probabilistic logic programming languages such as ProbLog, Markov logic networks, probabilistic soft logic — attaches probabilities or weights to logical facts and rules and computes the probability of conclusions. These are the natural bridge to neural networks, whose outputs are themselves probability distributions, and several of the integration architectures in the next chapter are built on them. The cost is computational: exact probabilistic inference is generally much harder than deterministic inference, and practical systems rely on approximation or on compiling the logic into special data structures that make inference tractable. Interactive theorem provers At the most expressive end are interactive theorem provers, or proof assistants: Lean, Coq (renamed Rocq in 2025), Isabelle/HOL and others. These implement very expressive logics — typically higher-order logic or dependent type theory — in which essentially any mathematical statement, and any property of any program, can be formalised. Proofs are constructed with substantial human guidance, though automation within the provers has become powerful, and increasingly with the help of language models. The decisive property of proof assistants is the small trusted kernel. However a proof is found — by a human, by automation, by a neural network — it is ultimately checked by a small core program that implements the logic's basic rules. That kernel is short enough to be scrutinised carefully, and in some cases has itself been verified. One therefore does not need to trust the process that found the proof, only the kernel that checks it. This is the purest form of the generate-and-verify pattern: an untrusted generator, however powerful and opaque, paired with a trusted checker whose correctness can be established independently. Proof assistants have been used to verify large, real systems. CompCert, a C compiler, was proved in Coq to preserve the meaning of the programs it compiles. The seL4 microkernel was proved correct in Isabelle/HOL against its specification in 2009. Lean's community library, Mathlib, contains a large and growing body of formalised mathematics. These achievements cost many person-years, which is one reason language models that can write formal proofs have attracted so much interest. The expressiveness–tractability trade-off Table 2 summarises the main formalisms against the properties that matter for checking neural outputs. Table 2. Principal symbolic formalisms compared. Formalism What it expresses well Decidability and cost World assumption Representative tools Propositional logic (SAT) Finite combinations of yes/no facts Decidable; NP-complete, often fast in practice Not applicable MiniSat, CaDiCaL, Kissat SMT Arithmetic, arrays, strings with logic Decidable for many theory combinations Not applicable Z3, cvc5 Datalog Recursive rules over large data Decidable; polynomial for fixed program Closed Soufflé, RDFox Description logic (OWL 2) Taxonomies, class definitions, relations Decidable; cost depends on profile Open HermiT, ELK, Pellet Answer set programming Defaults, exceptions, combinatorial search Decidable for finite programs; can be expensive Closed clingo First-order logic General rules over objects and relations Semi-decidable Open Vampire, E Higher-order logic and type theory Essentially all of mathematics and program semantics Proof checking decidable; proof finding not automatic Open Lean, Rocq, Isabelle/HOL Two practical lessons follow. First, choose the least expressive formalism that captures the constraints that matter. A drug-dosing check that requires only arithmetic and a lookup table belongs in SMT or even simple code, not in a higher-order theorem prover; the extra expressiveness buys nothing and costs automation. Conversely, a check that requires reasoning about class hierarchies belongs in a description logic rather than a hand-coded rule set that reimplements subsumption badly. Second, notice where the guarantee comes from. In every case, the guarantee attaches to the relationship between the premises and the conclusion. If the premises are wrong — the ontology has an error, the rule misstates the regulation, the specification omits a hazard — the logic will faithfully derive wrong conclusions. And if the premises were produced by a neural network translating natural language into logic, the logic guarantees nothing about whether that translation was faithful. This is the seam along which most neuro-symbolic systems are vulnerable, and it recurs in every chapter that follows. Chapter 4. Architectures of Integration There are many ways to join a neural network to a logical system, and they differ in where the boundary between the two sits, which direction information flows across it, and — most important for safety — which component has the last word. This chapter maps the main architectural patterns, explains how each works through representative systems, and assesses what kind of assurance each can provide. A taxonomy Henry Kautz's 2020 lecture proposed six categories, described with a compact notation that has stuck. The first, symbolic–neural–symbolic, is simply ordinary deep learning applied to symbolic data. A language model takes words in and produces words out; the words are symbols, but the processing between them is entirely neural. Kautz included it to make the point that symbols at the interface do not make a system neuro-symbolic in any interesting sense. The second, symbolic[neural], places a neural network inside a symbolic algorithm as a subroutine. The canonical example is AlphaGo, the system with which DeepMind defeated the Go champion Lee Sedol in 2016. Its outer structure is Monte Carlo tree search, a classical algorithm that explores possible sequences of moves. Neural networks supply two judgements inside that search: which moves are promising and how good a board position is. The search provides systematic look-ahead; the networks provide intuition about which branches to explore. The third, neural | symbolic, is a pipeline: a neural network converts raw perception into symbols, and a symbolic reasoner operates on those symbols. A system might use a vision network to identify objects and their attributes in an image, then answer a question about the image by executing a logical program over the extracted facts. The fourth, neural: symbolic → neural, uses symbolic systems to generate training data or supervision for a neural network. A symbolic engine produces large numbers of correct examples — solved equations, valid proofs, consistent scenarios — and the network learns from them. The trained network may never call the symbolic system at run time; the logic has been distilled into its weights. The fifth, written neural_symbolic, compiles logical rules into the structure or training objective of a network, so that the rules act as soft constraints shaping what it learns. The sixth, neural[symbolic], embeds a symbolic reasoning capability inside a neural system, which invokes it when needed. Kautz described this as the most ambitious category and largely a research goal in 2020. Since then, language models that call external solvers, interpreters and theorem provers as tools have made versions of it commonplace. Table 3 sets out the six categories with an example of each and an assessment of the assurance each typically provides. Table 3. Kautz's integration categories and the assurance they provide. Category How the parts relate Representative example Who has the last word Typical assurance Symbolic–neural–symbolic Symbols only at the interface Standard language model Network None beyond testing Symbolic[neural] Network is a subroutine of a symbolic algorithm AlphaGo's tree search Symbolic search, guided by network Search structure is explicit; quality depends on network Neural | symbolic Network perceives; logic reasons on its output Neuro-symbolic visual question answering Logic, given the perceived facts Reasoning is sound; perception is not checked Neural: symbolic → neural Logic generates training data Models trained on solver-generated proofs Network Improved accuracy; no run-time guarantee Neural_symbolic Rules shape training as soft constraints Logic Tensor Networks, semantic loss Network Rules usually satisfied; not guaranteed Neural[symbolic] Network invokes a reasoner as needed Language model calling a solver or prover Depends on whether the call is mandatory Strong if verification is enforced; weak if optional The final column matters most for this booklet's argument. Several of these patterns, including the most intellectually elegant, leave the neural network with final authority. They improve the network's behaviour without guaranteeing it. Others place a symbolic component in a position to reject or override, and only these offer guarantees of the kind safety-critical systems need. Pipelines: perception then reasoning The pipeline pattern is the oldest and most intuitive. Its research showcase was visual question answering on CLEVR, a synthetic benchmark released in 2017 consisting of rendered scenes of geometric objects and questions such as "Is the number of red cubes greater than the number of metal spheres?" Pure neural models performed reasonably but made errors on questions requiring counting or multi-step comparison. The Neural-Symbolic VQA system of Kexin Yi and colleagues, published in 2018, used a network to parse the scene into a structured table of objects and attributes and another to translate the question into a program, then executed the program symbolically. It achieved near-perfect accuracy, and its answers came with a fully inspectable trace: one could see exactly which objects were identified, what program was run and how it produced the answer. The Neuro-Symbolic Concept Learner of Jiayuan Mao and colleagues, published in 2019, showed that such a pipeline could learn visual concepts with far less supervision. The strength of the pipeline is clarity. The reasoning step is sound, and its inputs and outputs are explicit. If the system answers wrongly, one can determine whether perception or reasoning failed. The weakness is equally clear: the logic is only as good as the symbols it receives. If the vision network misidentifies a cylinder as a cube, the reasoner will correctly derive the wrong answer. Errors in perception propagate without check, and in synthetic benchmarks perception is easy; in the real world it is the hard part. Practical pipelines therefore often add a reverse check, in which the symbolic layer tests whether the perceived facts are jointly consistent with known constraints. An object tracked across video frames cannot teleport, change class arbitrarily or pass through a wall. A set of extracted laboratory values must satisfy known physiological relationships. When perceived facts violate such constraints, the pipeline knows that perception has failed, even if it does not know how. This turns a one-way pipeline into a two-way system and recovers some of the protection lost at the perceptual boundary. Differentiable logic: rules in the training loop A second family of approaches tries to make logic and learning work together during training rather than only at inference. The difficulty is that neural networks are trained by gradient descent, which requires every operation to be differentiable — to produce a smooth signal indicating how a small change in the weights would change the output. Classical logic is discrete: a statement is true or false, and there is no gradient. Several techniques relax logic into a differentiable form. Logic Tensor Networks, introduced by Luciano Serafini and Artur d'Avila Garcez in 2016 and developed further by Samy Badreddine and colleagues, interpret logical predicates as neural networks that output truth degrees between zero and one, and interpret connectives and quantifiers using operators from fuzzy logic. A knowledge base of first-order rules then becomes a differentiable objective: the network is trained to maximise the degree to which the rules are satisfied, alongside fitting the data. If the rules say that every smoker has an elevated risk of a particular disease, the learned predicates are pushed toward satisfying that. The semantic loss of Jingyi Xu, Guy Van den Broeck and colleagues, published in 2018, takes a more principled probabilistic route. Given a logical constraint over a network's outputs — exactly one of these labels must be true; the predicted path must be connected; the predicted ranking must be a valid permutation — the semantic loss measures the probability that a sample from the network's output distribution would satisfy the constraint. To compute this efficiently, the constraint is compiled into a data structure from the field of knowledge compilation that supports fast probabilistic queries. Training with the semantic loss substantially improves accuracy on structured prediction tasks, especially with limited labelled data, because the constraint supplies information the labels do not. DeepProbLog, introduced by Robin Manhaeve and colleagues in 2018, extends the probabilistic logic programming language ProbLog with "neural predicates" whose probabilities are computed by networks. A standard demonstration trains digit recognisers using only the sums of pairs of handwritten digits as supervision: the program knows that the label is the sum of two digits, and gradients flow back through the logical inference to the digit classifier, which learns to recognise individual digits without ever being told what any single one is. Scallop, developed by Ziyang Li, Jiani Huang and Mayur Naik and published in 2023, applies a similar idea to a Datalog-based language with a more scalable approximation scheme. Systems for differentiable inductive logic programming, such as the ∂ILP system of Richard Evans and Edward Grefenstette, go further and learn the logical rules themselves from examples. These approaches are scientifically important. They show that logical knowledge can make learning more data-efficient, that networks trained against constraints generalise more systematically, and that the boundary between learning and reasoning is less sharp than the old debate suggested. But they have a limitation that matters for safety. In most of them, the logic shapes training without enforcing anything at run time. A network trained to satisfy a constraint will usually satisfy it on inputs resembling its training data, and may violate it elsewhere. The guarantee is statistical. For a safety-critical constraint — never prescribe this drug to a patient with that allergy — "usually satisfied" is not enough. There is a straightforward remedy, and it shows how the patterns combine: train with the constraint for accuracy, then enforce it at inference for safety. Many structured prediction problems allow the network's output distribution to be restricted at inference time to outputs that satisfy the constraint, either by filtering or by constrained search. The training-time constraint makes the network's best answer more likely to be valid; the inference-time constraint makes an invalid answer impossible. Constrained generation Constrained decoding is the inference-time enforcement idea applied to language models, and it is one of the most practically useful neuro-symbolic techniques in deployment today. A language model generates text one token at a time by sampling from a probability distribution. At each step, a symbolic component can determine which tokens would keep the output consistent with a formal grammar or schema and mask out the rest. The model then chooses only among valid continuations. If the required output is JSON matching a particular schema, a constrained decoder guarantees that the result parses and conforms. If it is SQL, the PICARD system of Torsten Scholak and colleagues, published in 2021, showed that incremental parsing during decoding could reject invalid queries and improve accuracy substantially on text-to-SQL benchmarks. Libraries such as Outlines and Guidance, and the structured-output features of major model providers, make grammar-constrained decoding routine. The guarantee here is real but narrow. A constrained decoder guarantees syntactic validity — the output conforms to the grammar. It does not guarantee that the content is correct: a perfectly formed JSON object can contain a wrong dosage, and a valid SQL query can retrieve the wrong rows. Constraints can be made semantic as well as syntactic, by having the decoder consult a solver at each step to ensure the partial output remains satisfiable with respect to richer conditions, but this is more expensive and less mature. Constrained decoding is best seen as a guarantee about form that reduces the space in which content errors can occur, rather than as a guarantee about content. Tool use and the authority question The pattern most visible in current practice is a language model that calls symbolic tools: a calculator, a code interpreter, a database, a search engine, an SMT solver, a theorem prover. This is Kautz's sixth category in its modern form, and it can be powerful. A model that delegates arithmetic to a calculator does not make arithmetic errors. A model that writes a program and executes it, as in the program-aided language models of Luyu Gao and colleagues published in 2023, offloads computation to an interpreter whose behaviour is exact. But tool use raises the authority question in its sharpest form. In a typical agentic system, the model decides whether to call a tool, decides what to pass to it, receives the result and decides what to do with it. At every step the network has the last word. It can skip the tool, misformulate the query, misread the result, or override it with its own judgement. Tool use improves average accuracy; on its own, it guarantees nothing. Converting tool use into a guarantee requires changing the architecture so that the symbolic step is not optional. The model's output is not released until a verifier has accepted it. The verifier receives the output directly, not the model's summary of it. The verifier's verdict is final: if it rejects, the output is not released, whatever the model says. And the verifier's own inputs — the rules, the knowledge base, the specification — are controlled by the system's designers, not generated by the model. This pattern, in which the neural component is an untrusted generator and a symbolic verifier is the gatekeeper, is the one that runs through the rest of this booklet. It can be built on any of the formalisms of the previous chapter, and its strength depends on exactly what the verifier checks. Choosing a pattern No single architecture is best. The appropriate choice depends on where errors are most likely and most costly. When perception is reliable and reasoning is complex, a pipeline with a sound reasoner is efficient and transparent. When reasoning is easy but perception is hard, consistency checks on perceived facts do more good than an elaborate reasoner. When labelled data is scarce but domain knowledge is rich, differentiable logic during training improves accuracy cheaply. When outputs must have a particular form, constrained decoding provides a cheap, strong guarantee about structure. When outputs must be correct in substance and errors are expensive, a mandatory verifier with authority to reject is the only pattern that provides a guarantee. Real systems layer these. A clinical documentation assistant might use constrained decoding to ensure that its output follows a structured template, ground every coded diagnosis in an ontology, check every medication order against a rule base for interactions and contraindications, and route anything the checks cannot confirm to a clinician. Each layer addresses a different failure type from Chapter 1, and each has a stated scope. The next three chapters examine the most important of these layers — grounding in ontologies, verification of reasoning, and verification of the network itself — in detail. Chapter 5. Ontologies, Knowledge Graphs and the Problem of Grounding The first defence against a neural network's factual errors is to give it, or its supervisor, something authoritative to check against. Retrieval-augmented generation — fetching relevant documents and placing them in a language model's context — is the most common version, and it reduces hallucination considerably. But documents are themselves unstructured text, and a model can misread, misquote or ignore them. A stronger form of grounding uses structured knowledge whose meaning is formally defined: ontologies and knowledge graphs. This chapter explains what these are, how they constrain neural outputs, and where their limits lie. What an ontology is In computer science, an ontology is a formal specification of the concepts in a domain and the relationships among them. It answers questions such as: what kinds of things exist here, how are they classified, what properties do they have, and what must be true of them? An ontology for pharmacology might say that every drug has one or more active ingredients, that a beta-blocker is a kind of antihypertensive, that a contraindication relates a drug to a condition, and that a drug cannot be both an agonist and an antagonist at the same receptor. The difference between an ontology and a mere vocabulary or list of terms is that an ontology's statements are logical axioms with defined consequences. If the ontology says that every bacterial pneumonia is a pneumonia, that every pneumonia is a lung disease, and that a particular patient has bacterial pneumonia, then a reasoner can derive that the patient has a lung disease without anyone having stated it. If the ontology says that the classes "viral organism" and "bacterial organism" are disjoint, then any assertion that the same organism is both is detectably inconsistent. The major biomedical ontologies illustrate the scale and seriousness of this work. SNOMED CT, maintained by the standards body SNOMED International, defines clinical concepts — findings, disorders, procedures, organisms, substances, body structures — with logical definitions in a description logic, and is used for coding in electronic health records across many countries. The Gene Ontology, begun in 1998, defines molecular functions, biological processes and cellular components, and is used to annotate genes across many species. The Basic Formal Ontology, an upper-level framework standardised as ISO/IEC 21838-2 in 2021, provides a common foundation on which hundreds of domain ontologies in science and medicine are built, so that they can interoperate. RxNorm, maintained by the US National Library of Medicine, normalises drug names and links them to ingredients, strengths and dose forms. Outside biomedicine, the Financial Industry Business Ontology formalises concepts in financial contracts and instruments; industrial ontologies describe equipment, processes and failure modes in manufacturing and energy; legal ontologies attempt to formalise concepts in statutes and contracts. The quality and maturity of these vary considerably, a point that matters when they are used as a check. Knowledge graphs A knowledge graph is a large collection of facts represented as a network of entities connected by typed relations: a drug treats a condition, a company is headquartered in a city, a gene encodes a protein. Google popularised the term in 2012 for the structured knowledge behind its search results. Wikidata, the collaboratively edited knowledge base associated with Wikipedia, contains over a hundred million items. Many organisations maintain internal knowledge graphs of their products, customers, assets and processes. Knowledge graphs and ontologies overlap. Roughly, the ontology supplies the schema — the classes, relations and axioms — and the knowledge graph supplies the instances. A well-built knowledge graph is typed by an ontology, so that a reasoner can check that the facts it contains respect the ontology's constraints and derive further facts from them. In practice, many knowledge graphs have only light schemas, and the distinction between curated knowledge and extracted data blurs. Three ways to ground a neural output There are three main ways to use structured knowledge to discipline a neural model, and they offer different levels of assurance. The first is grounding at input. Relevant facts are retrieved from the knowledge graph and placed in the model's context, so that the model generates from them rather than from its parametric memory. This is retrieval-augmented generation with structured rather than textual sources. Microsoft's GraphRAG work, published in 2024, and a range of similar systems retrieve subgraphs or community summaries from a knowledge graph to answer questions that require connecting information across many documents. Grounding at input improves accuracy because the model has the right facts in front of it. It does not guarantee accuracy, because the model can still ignore, misread or embellish them. The neural network retains final authority. The second is grounding at output, or validation. The model generates freely, and its output is then parsed into structured claims — entities, relations, attribute values — which are checked against the knowledge graph and ontology. Claims that the knowledge base confirms pass. Claims that it contradicts are rejected. Claims it neither confirms nor contradicts are flagged as unverified. This places the symbolic component in the position of authority, and it can deliver a real guarantee: no claim that contradicts the knowledge base reaches the user. The weak point is the extraction step, since parsing free text into structured claims is itself typically done by a neural model and can miss or distort claims. The third is grounding by construction. The output is assembled from the knowledge base rather than generated and then checked. The model's role is to interpret the user's request — to translate a natural-language question into a structured query — and the answer is produced by executing that query against the knowledge base. Optionally, the model then renders the structured answer back into fluent prose under constraints that prevent it from adding content. Text-to-SQL and text-to-SPARQL systems work this way. The guarantee is that every fact in the answer comes from the knowledge base. The weak point is the translation of the question: a mistranslated query returns a correct answer to the wrong question. These three can be combined, and the best systems combine all of them: retrieve relevant structured facts, generate under constraints, validate the output against the knowledge base, and present answers with explicit provenance showing which facts in the knowledge base support each claim. What a reasoner adds A knowledge graph alone supports lookup: is this triple present? An ontology with a reasoner supports inference: does this claim follow from what is present, or contradict it? The difference is large in practice. Consider a model that states that a patient with a sulfonamide allergy may safely receive a particular diuretic. A lookup in a drug knowledge base might find no stored triple linking that patient's allergy to that specific diuretic. A reasoner, however, can use the ontology's axioms: the diuretic contains a sulfonamide moiety; the patient's allergy is to the class of sulfonamide-containing compounds; therefore the diuretic falls within the allergy class. Whether that cross-reactivity is clinically significant is a matter of medical judgement, and the ontology's design must reflect current evidence on it — but the point is that the relevant conclusion was never stated explicitly. It followed from general axioms. Lookups catch only the errors someone anticipated; reasoning catches errors that follow from principles. Reasoners also detect inconsistency in the model's output as a whole. A discharge summary that records a diagnosis of type 1 diabetes and also states that the patient has never required insulin contradicts axioms about the disease. A financial report that classifies an instrument as both a debt and an equity instrument under a scheme that defines these as disjoint is inconsistent. Each claim might pass a lookup individually; the conjunction fails. Where grounding fails The appeal of grounding is that it places a curated source of truth between the model and the user. Its limitations follow from the fact that the source of truth is itself a human artefact. Coverage. No knowledge base is complete. Under the open-world assumption, an absent fact is unknown rather than false, so a validator must decide what to do with claims it cannot confirm. If it rejects them, the system becomes unhelpfully conservative, refusing to state anything not already recorded. If it accepts them, the guarantee shrinks to "nothing contradicts the knowledge base", which is weaker than "everything is supported by it". The right policy depends on the domain. In clinical dosing, unconfirmed claims should not reach a patient. In exploratory research, they may be exactly what is wanted, appropriately labelled. Currency. Knowledge changes. Drug labels are revised, regulations amended, companies merge, guidelines are updated. A knowledge base that lags the world will reject true claims and confirm false ones. Maintenance is a continuous cost, and it is where the knowledge acquisition bottleneck of the expert-systems era reappears. Large ontologies are maintained by dedicated teams, with formal editorial processes, regular releases and quality assurance. An organisation that builds its own knowledge graph to ground a language model has acquired, whether it realises it or not, a permanent maintenance obligation. Errors in the knowledge base. Curated sources contain errors. Studies of large biomedical ontologies have found inconsistent or incorrect axioms; collaboratively edited knowledge bases contain vandalism and mistakes. A validator that trusts the knowledge base absolutely will enforce its errors. Mature systems therefore treat the knowledge base as authoritative but fallible, maintain provenance for each fact, and provide ways for users to report suspected errors. Modelling choices. Every ontology embodies decisions about how to carve up a domain, and those decisions may not suit every use. A disease classification designed for billing may not distinguish clinically important subtypes. An ontology that represents a legal concept one way may conflict with how a particular jurisdiction's courts interpret it. Grounding a model in an ontology commits the system to that ontology's view of the world, including its blind spots. The extraction gap. Validation at output requires converting the model's free text into structured claims. If the extractor misses a claim, the claim is never checked. If it misinterprets a hedged statement as a definite one, or vice versa, the check is applied to the wrong claim. Robust systems reduce this gap by constraining the model to produce structured output directly, so that there is less free text to interpret, and by having the extractor flag spans of text it could not map to any structured claim, so that unchecked content is visible. Neural methods in the service of ontologies The relationship runs in both directions. Building and maintaining ontologies is labour-intensive, and neural methods are increasingly used to assist: proposing new concepts and relations from the literature, mapping terms between ontologies, detecting likely errors, and linking mentions in text to ontology concepts. Entity linking — recognising that "heart attack", "MI" and "myocardial infarction" in clinical notes all refer to the same SNOMED CT concept — is a task at which neural models excel and symbolic methods struggle. This creates a delicate dependency. If neural methods help build the knowledge base that is then used to check neural outputs, errors can circulate. A language model that proposes a false relation, accepted into the knowledge graph by an inattentive curator, will later have its own hallucinations confirmed. The safeguard is to keep the curation step genuinely human, with neural proposals reviewed against primary evidence before acceptance, and to record the provenance of every assertion so that machine-proposed facts can be identified and audited. A worked illustration Consider a system that drafts responses to pharmacists' questions about drug interactions. A purely neural design would answer from the model's training, perhaps augmented with retrieved monographs. The responses would be fluent and usually correct, and the errors would be indistinguishable from the correct answers. A grounded design proceeds differently. The model first identifies the drugs in the question and links each to a normalised identifier in a drug terminology. If any drug cannot be linked, the system asks for clarification rather than guessing. The interaction knowledge base — a curated, versioned source maintained by clinical pharmacists — is queried for interactions among the identified drugs, and a reasoner applies class-level rules, so that an interaction recorded for a drug class is inferred for its members. The model then drafts a response under a constraint: every interaction it mentions must correspond to an interaction returned by the query, and every interaction returned must be mentioned. A validator parses the draft and checks both conditions. If the draft mentions an interaction not in the result set, or omits one that is, it is rejected and regenerated, or the structured result is presented directly. The final response cites the knowledge base entries that support it, with their version and date. This system can still be wrong. The knowledge base may be out of date or mistaken; the entity linking may pick the wrong drug; the clinical significance of an interaction may depend on patient factors the system does not know. But its failures have a different character. They are attributable to identifiable components, they can be audited after the fact, and the most common neural failure — fluent invention of an interaction that does not exist, or confident omission of one that does — has been structurally excluded. That is what grounding offers: not truth, but a narrowing of where falsehood can enter, and a record of where it did. Chapter 6. Deduction as Verifier: Checking the Reasoning Grounding addresses false facts. A different class of error remains: a model can start from correct premises and reason its way to a wrong conclusion. It can drop a constraint halfway through a long argument, confuse "some" with "all", reverse the direction of an implication, or make an arithmetic slip that propagates through every later step. These errors are especially dangerous because the surrounding reasoning looks sound. A reader who checks the premises and the general shape of the argument may not notice the one step that fails. The symbolic remedy is to have the reasoning checked by a system that cannot make these errors — or, better still, to have the reasoning performed by such a system, with the neural network supplying only the parts it is uniquely good at. This chapter examines the patterns by which this is done, from simple delegation of computation to full formal proof. Why language models reason unreliably Modern language models reason far better than their predecessors. Prompting them to produce intermediate steps — the "chain of thought" technique described by Jason Wei and colleagues in 2022 — improved accuracy on multi-step problems markedly, and models subsequently trained with reinforcement learning to produce long internal reasoning traces before answering now solve problems in competition mathematics and programming that were far out of reach in 2022. Yet the underlying mechanism has not changed. Each step of a chain of thought is a generated token sequence, produced by the same predictive process as everything else. Research on these traces has found that they are not always faithful to the computation that produced the answer: a model may reach an answer by some internal route and then generate a plausible-looking justification that does not reflect it. Steps can be locally fluent and globally wrong. The model has no built-in mechanism to guarantee that step n+1 actually follows from steps 1 through n. Sampling multiple chains and taking a majority vote, a technique known as self-consistency, improves accuracy further, as does training a separate neural "verifier" or "process reward model" to score each step. These help on average. But a neural verifier is a predictor of correctness, not a test of it, and it shares many of the blind spots of the generator. Where the problem has a formal structure, a symbolic checker can do something no neural verifier can: determine with certainty whether the reasoning is valid. Delegating computation The simplest form of symbolic reasoning support is delegation of computation. Rather than performing arithmetic or symbolic manipulation in text, the model writes code that performs it, and an interpreter executes the code. Program-aided language models, described by Luyu Gao and colleagues in 2023, and the related "program of thoughts" approach showed substantial improvements on mathematical word problems by this route. The model translates the problem into a program; the interpreter computes the answer exactly. This pattern is now ubiquitous. Assistants that analyse data write and execute code rather than estimating; agents that manipulate spreadsheets call spreadsheet functions rather than reasoning about cell values. The guarantee is that the computation is performed correctly. It is not a guarantee that the right computation was performed. If the model misreads the problem and writes code that computes the wrong quantity, the interpreter will compute the wrong quantity flawlessly. Translating to logic A more ambitious pattern translates a reasoning problem into a formal logic and hands it to a solver. Logic-LM, described by Liangming Pan and colleagues in 2023, used a language model to translate natural-language logical reasoning problems into the input language of an appropriate solver — a logic programming engine, a first-order theorem prover, or a constraint solver, depending on the problem type — and then ran the solver. When the solver reported a syntax error, the error message was fed back to the model to repair its translation. LINC, described by Theo Olausson and colleagues in the same year, translated premises and conclusions into first-order logic and used the Prover9 theorem prover to determine whether the conclusion followed. Both reported substantial gains over chain-of-thought prompting on benchmarks of deductive reasoning, with the gains largest on problems requiring many steps. These systems clarify the general shape of the approach, which has two halves. The first half — translating from natural language into logic — is a task neural networks are good at and symbolic systems cannot do. The second half — determining what follows from the logical statements — is a task symbolic systems do perfectly and neural networks do unreliably. The division of labour is principled. The weakness is the translation, which is often called autoformalisation. If the model translates "every employee who has worked here more than five years is eligible" as a statement about employees who have worked at least five years, the solver will correctly derive a wrong eligibility conclusion. The research systems found that translation errors were the dominant source of residual failures. Several remedies are used in practice. One is round-trip checking: translate the formal statement back into natural language with a separate model or prompt, and compare it to the original. Discrepancies suggest a translation error. This is imperfect, because the back-translation can smooth over subtle differences, but it catches gross errors cheaply. A second is multiple independent translations: generate several formalisations and check whether they are logically equivalent, which a solver can determine. If they disagree, the input is ambiguous or the translation is unreliable, and the system can ask for clarification. This turns the solver into a detector of translation uncertainty. A third is human review of the formalisation. In settings where the same rules are applied repeatedly — a regulation, a policy, an eligibility scheme — the formal translation of the rules can be produced once, with neural assistance, and then reviewed and approved by domain experts. At run time, only the facts of the particular case need to be translated, which is a much simpler task. This is the pattern adopted by most serious deployments, and it relocates the hardest translation problem from run time, where errors go unseen, to design time, where they can be caught. A fourth is testing the formalisation. Formal rules can be tested systematically against cases whose correct outcomes are known, and solvers can generate edge cases automatically — inputs that sit exactly on the boundaries of the rules — for experts to adjudicate. A formalisation that has survived systematic boundary testing is much more trustworthy than one that has merely been read. Neural search, symbolic proof The most striking results in neuro-symbolic reasoning have come from mathematics, where the formal criterion of correctness is unambiguous and proof checkers are mature. AlphaGeometry, described by Trieu Trinh and colleagues in Nature in January 2024, solved olympiad-level Euclidean geometry problems by combining a language model with a symbolic deduction engine. The deduction engine applies geometric rules exhaustively to derive everything that follows from the current set of facts about a diagram. Geometry problems are often hard because the proof requires an auxiliary construction — a point, line or circle not in the original problem — that a deduction engine cannot invent. The language model's job was to propose such constructions. The engine then tried again with the enlarged diagram. The language model had been trained on a very large set of synthetic proofs generated by the symbolic engine itself, so this is also an instance of the "symbolic generates training data for neural" pattern. On a benchmark of thirty olympiad geometry problems, AlphaGeometry solved twenty-five, approaching the average performance of human gold medallists, and every solution was a machine-checkable deduction. AlphaProof, announced by Google DeepMind in July 2024 and described in Nature in 2025, worked in Lean, a general-purpose proof assistant. Competition problems were translated into Lean statements, and a reinforcement learning system searched for proofs, receiving reward only when the Lean kernel accepted a proof as valid. Together with an improved version of AlphaGeometry, the system solved four of the six problems at the 2024 International Mathematical Olympiad, a performance equivalent to a silver medal. The crucial feature is that the proofs were verified by construction. Whatever the neural search did internally, the output was a Lean proof that the kernel had checked. There was no possibility that a solution looked right but was wrong. The following year, as noted in Chapter 2, a natural-language system reached gold-medal standard without formal proof, its solutions graded by human markers. This is an important result, and it shows that formal machinery is not necessary for high capability. But it also clarifies what formal machinery is for. The natural-language solutions had to be checked by expert mathematicians. The Lean proofs checked themselves. For a mathematics competition, human grading is acceptable. For a system generating thousands of proofs of software properties a day, or certifying the safety of a control algorithm, it is not. The capability can come from either route; the guarantee comes only from the formal one. The same pattern is spreading beyond competition mathematics. Language models trained to write Lean proofs are being used to assist professional mathematicians with formalisation. In software verification, models propose loop invariants, specifications and proof steps for verification tools such as Dafny, Verus and F*, and the tools accept or reject each proposal. Because the verifier is sound, a model that proposes a wrong invariant cannot cause an incorrect program to be accepted; it can only fail to complete the proof. The worst outcome of neural error is wasted effort rather than false assurance. The asymmetry that makes it work Underlying all of these systems is an asymmetry between finding and checking. For many problems of practical interest, finding a solution is hard but checking a proposed solution is easy. Finding a proof of a theorem may require insight; checking a proof is mechanical. Finding a satisfying assignment for a set of constraints may require search; checking one requires only evaluation. Finding a loop invariant that makes a program verifiable is an art; checking that a proposed invariant works is automatic. Neural networks are excellent at the hard, heuristic, insight-requiring part. Symbolic checkers are excellent at the easy, mechanical, certainty-requiring part. A system that uses each for what it does well inherits the network's power and the checker's reliability. Because the checker is sound, the network's errors can only cause failure to find a solution, never acceptance of a wrong one. This is the deepest reason the generate-and-verify pattern is the backbone of neuro-symbolic safety: it makes the network's unreliability safe. The asymmetry does not hold for every problem. Some outputs — an open-ended medical summary, a strategic recommendation, a piece of creative writing — have no formal criterion against which they can be checked. For these, symbolic verification can check only fragments: the facts mentioned, the arithmetic performed, the constraints that must hold. An important design skill is identifying which parts of an output are formally checkable, checking those rigorously, and being explicit about which parts remain unchecked. Checking reasoning that is not mathematics Most reasoning in safety-critical domains is not mathematical proof. It is the application of rules to facts: does this transaction comply with these regulations; is this patient eligible for this trial; does this design meet this specification; does this access request satisfy this policy. Such reasoning is well suited to symbolic verification once the rules have been formalised. A pattern that has emerged for these cases runs as follows. The rules are formalised in advance, with neural assistance and expert review, into a logic that a solver handles well — often SMT or Datalog. At run time, a language model handles a user's question and produces an answer. The answer, together with the facts of the case, is translated into logical assertions. The solver checks whether the answer's claims are entailed by the rules and facts, contradicted by them, or neither. If entailed, the answer is released with a note of which rules support it. If contradicted, it is rejected, and the solver can produce a counterexample or the specific rule violated, which can be used to correct the answer. If neither, the answer is flagged as not determined by the rules, which often indicates either a gap in the formalisation or an ambiguity in the question. Chapter 9 examines production systems built on this pattern. Its strength is that it gives a precise account of what has and has not been checked. Its weakness, as always, lies in the translations — of the rules at design time and of the facts and answer at run time — and good systems invest heavily in making those translations visible, testable and reviewable. The limits of checking reasoning Formal verification of reasoning answers one question precisely: does the conclusion follow from the premises? It does not answer whether the premises are true, whether the formalisation captures what the rules meant, or whether the question asked was the right one. A sound solver applied to a mistranslated regulation produces a confident, verified, wrong answer — and the word "verified" may make it more dangerous than an unverified one, because it discourages further scrutiny. The defence is to report verification results with their scope attached. Not "verified", but "verified against version 3.2 of the formalised eligibility rules, given these extracted facts". The extracted facts can be displayed for confirmation. The rule version can be traced to the expert review that approved it. A user who sees the scope of a verification can judge whether it covers what they need. A user who sees only the word "verified" cannot. This is not a cosmetic point. The value of symbolic methods lies in making assumptions explicit; a system that hides them throws that value away. Chapter 7. Verifying the Network Itself The patterns of the previous two chapters treat the neural network as a black box and check its outputs. A different approach opens the box. A trained network is, after all, a mathematical function — a fixed composition of matrix multiplications and simple nonlinearities — and mathematical functions can have their properties proved. Formal verification of neural networks aims to establish, with mathematical certainty, that a network's outputs satisfy a stated property for every input in a stated region, not merely for the inputs that happened to be tested. This is the most direct answer to the question "can we trust the network?", and it has produced real results in safety-critical settings. It also has severe limits of scale and, more fundamentally, of specification. This chapter explains both. From testing to proof Conventional machine-learning evaluation is empirical. A network is run on a held-out test set and its accuracy measured. If it performs well, one infers that it will perform well on similar inputs in deployment. This inference is statistical and depends on the test set being representative. It says nothing about inputs unlike those tested, and in a high-dimensional input space — an image has hundreds of thousands of pixel values — almost all possible inputs are unlike those tested. Adversarial examples showed how badly this inference can fail. A network that classifies a test set with high accuracy may change its answer when an input is perturbed by an amount imperceptible to a human. Testing on clean inputs gives no warning. Testing on adversarially perturbed inputs, generated by attack algorithms, is better, but an attack that fails to find a perturbation does not prove none exists. Verification asks the universal question directly. A typical property is local robustness: for a given input and a given perturbation budget — say, every pixel may change by at most a small amount — does the network assign the same class to every input within that region? Other properties concern safety-critical outputs: for every input in a region of the sensor space corresponding to an intruder aircraft approaching from the left, does a collision-avoidance network never advise turning left? A verifier either proves the property holds throughout the region, or finds a counterexample — a specific input that violates it — or, in some methods, reports that it cannot decide. The ACAS Xu case The case that established the field involved aircraft collision avoidance. The Airborne Collision Avoidance System X (ACAS X) is a family of collision-avoidance systems developed for the US Federal Aviation Administration. Its unmanned-aircraft variant, ACAS Xu, uses a large table of precomputed advisories derived from an optimisation over a probabilistic model of encounter dynamics. The table was too large for convenient use in avionics hardware, and in 2016 Kyle Julian, Mykel Kochenderfer and colleagues showed that it could be compressed into a set of forty-five small neural networks, each mapping sensor inputs to advisory scores, with a dramatic reduction in storage. The compression raised an obvious question. The original table had been designed and validated carefully. Did the networks preserve its safety properties, or had compression introduced unsafe advisories in regions between the training points? Testing could not answer this conclusively. In 2017, Guy Katz, Clark Barrett, David Dill, Kyle Julian and Mykel Kochenderfer introduced Reluplex, a verification algorithm for networks using the common ReLU activation function, and applied it to the ACAS Xu networks. They formalised ten properties the networks should satisfy — for example, that if an intruder is far away and moving away, the advisory should be "clear of conflict" — and proved several of them, while finding counterexamples to others. The work showed that formal verification of real, safety-relevant networks was feasible, and also demonstrated that a network trained to approximate a safe table could deviate from it in specific, discoverable ways. The ACAS Xu networks became the standard benchmark for the field, and their history illustrates a broader principle. They were amenable to verification partly because they were small — six hidden layers of fifty neurons each — and partly because their inputs were low-dimensional and physically meaningful, so that properties could be stated in terms engineers understood. Both features are absent in most modern deep-learning applications. How verifiers work A network with ReLU activations computes a piecewise-linear function. Each ReLU neuron is either active (passing its input through) or inactive (outputting zero), and within any region where every neuron's state is fixed, the network is simply a linear function of its input. Verification of a linear function over a region defined by linear constraints is easy; it is linear programming. The difficulty is that a network with n ReLU neurons has up to two to the power n combinations of neuron states, and the verification problem is in general NP-complete, as Katz and colleagues proved. Verification methods divide into two broad families. Complete methods give a definite answer for every property: either a proof or a counterexample, given enough time. Reluplex extended the simplex algorithm for linear programming to handle ReLU constraints lazily, splitting on a neuron's state only when necessary. Its successor, Marabou, released in 2019, added further techniques and became a widely used open-source tool. Other complete methods encode the verification problem as a mixed-integer linear program and hand it to a commercial optimisation solver. Complete methods are exact but scale poorly; their worst-case cost grows exponentially with the number of neurons that cannot be resolved. Incomplete methods compute over-approximations. Rather than determining exactly what outputs the network can produce over an input region, they compute a guaranteed superset. If the property holds over the superset, it holds over the true output set, and the network is proved safe. If the superset includes a violating output, the method cannot tell whether the violation is real or an artefact of over-approximation, and reports "unknown". The simplest form, interval bound propagation, pushes intervals through the network layer by layer. More precise methods track linear relationships between neurons. The AI2 system of Timon Gehr and colleagues, published in 2018, adapted abstract interpretation — a framework for sound static analysis of programs developed by Patrick and Radhia Cousot in the 1970s — to neural networks. DeepPoly, from Gagandeep Singh and colleagues at ETH Zurich in 2019, and the CROWN family of bound-propagation methods developed by Huan Zhang and colleagues offered tighter approximations at modest cost. The best modern verifiers combine both. They use fast bound propagation to prove what can be proved cheaply, and when bounds are too loose, they split the problem into sub-problems — fixing the state of an uncertain neuron or dividing the input region — and bound each sub-problem more tightly. This branch-and-bound approach, combined with GPU acceleration and optimised bounds, underlies α,β-CROWN, which has won the annual International Verification of Neural Networks Competition (VNN-COMP) in most years since the competition began in 2020. A third approach provides probabilistic rather than deterministic guarantees. Randomised smoothing, introduced in its now-standard form by Jeremy Cohen, Elan Rosenfeld and Zico Kolter in 2019, constructs a new classifier that outputs the most likely class of the original network under random noise added to the input. For the smoothed classifier, a robustness radius can be certified with high statistical confidence. The guarantee is genuine but probabilistic, holding with a stated confidence level over the randomness of the noise, and it applies to the smoothed classifier rather than the original network. Randomised smoothing scales to large networks where deterministic verification is infeasible. Table 4 compares these families. Table 4. Families of neural network verification methods. Method family Guarantee Answer when property is uncertain Scalability Representative tools Complete (SMT, MILP-based) Exact proof or counterexample Always decides, given time Small to medium networks Reluplex, Marabou, MILP encodings Incomplete (bound propagation, abstract interpretation) Sound proof when it succeeds Reports unknown Medium to large networks AI2, DeepPoly, CROWN Branch and bound (hybrid) Proof or counterexample; may time out Refines until decided or timeout Medium to large, GPU-accelerated α,β-CROWN Randomised smoothing Probabilistic certificate for smoothed model Abstains Large networks Smoothing-based certifiers What has been verified, and what has not Verification has been applied successfully to networks in aircraft collision avoidance, to small control networks for autonomous systems, to perception components with restricted input spaces, and to robustness properties of image classifiers up to moderate size. The annual competition has driven steady improvement, and verifiers now handle networks with hundreds of thousands or millions of parameters for some properties. But there is a large gap between what can be verified and what is deployed. Frontier language models have hundreds of billions of parameters, and their inputs are discrete sequences of tokens of variable length. No current method can verify meaningful semantic properties of such models, and none is in prospect. Even for image classifiers, the properties that can be verified — robustness within a small perturbation of a specific input — are far narrower than the properties one actually cares about. Researchers have responded by training networks to be easier to verify. Certified training incorporates bounds from verification methods into the training objective, producing networks whose robustness can be proved more often, typically at some cost in clean accuracy. Architectural choices — smaller networks, specific activation functions, enforced sparsity, Lipschitz constraints that bound how fast the output can change with the input — also improve verifiability. This is an important lesson for safety-critical design: if a component must be verified, it should be designed for verification from the start, not built for maximum accuracy and verified afterwards. The specification problem The deepest limit of network verification is not computational. It is the difficulty of stating what the network should do. For ACAS Xu, properties could be stated in terms of physical quantities: distance, angle, speed. For an image classifier, what would a correctness specification look like? "The network should classify every image of a pedestrian as a pedestrian" is not a formal statement, because "image of a pedestrian" has no formal definition. If it did, we would not need a neural network; we would implement the definition directly. The network exists precisely because the concept cannot be formalised. What can be specified are properties around the concept: robustness to small perturbations, consistency under transformations such as rotation or brightness change, monotonicity in certain inputs, bounds on outputs in particular regions. These are useful, but they are not correctness. A network can be provably robust around every test image and still misclassify the test images themselves, or be robust around the wrong answer. This is the symbol grounding problem from Chapter 2, returning in a new form. Formal verification needs a formal specification. The tasks for which neural networks are indispensable — perception, language understanding, pattern recognition in rich data — are exactly the tasks for which formal specifications cannot be written. Verification can prove that a network has certain mathematical properties; it cannot prove that the network perceives correctly, because "correctly" is not a mathematical property. Verification at run time A complementary idea moves part of the verification effort from design time to run time. Instead of proving a property over an entire input region in advance, the system checks, for each input it actually receives, whether that input lies in a region where the network's behaviour is trusted. The simplest version is a monitor on the network's inputs. If the network was validated on inputs drawn from a particular distribution — images taken in daylight, sensor readings within known ranges, text in a particular language and domain — a monitor can test whether each new input resembles that distribution and flag those that do not. Out-of-distribution detection methods range from simple range checks on input features to learned density estimates. The learned versions are themselves neural and fallible, but they need not be perfect to be useful: their job is to raise a flag, not to make a decision, and a flag that is sometimes raised unnecessarily costs only caution. A more principled version monitors the network's internal activations. Researchers have proposed recording which patterns of neuron activation occur on validated inputs, and treating an input that produces an unfamiliar activation pattern as a sign that the network is operating outside its experience. Such monitors can be expressed as explicit, inspectable data structures — sets of observed activation patterns, or abstractions of them — and checked quickly at run time. A third version performs a small verification for each input. A robustness certificate can be computed for the specific input received, establishing that small perturbations would not change the output. If certification succeeds, the output is stable; if it fails, the output sits near a decision boundary and deserves less trust. For small networks, bound propagation is fast enough to do this in real time. None of these run-time techniques proves that the network's output is correct. What they provide is a principled signal that the output was produced under conditions resembling those in which the network was validated, and that it is not balanced on a knife edge. Such a signal is exactly what a runtime assurance architecture needs to decide when to trust the learned component and when to fall back, and it links this chapter to the next. Where network verification fits Verifying the network itself is therefore most valuable in a specific niche: small to medium networks, with low-dimensional, physically meaningful inputs, implementing functions whose safety-relevant properties can be stated in terms of those inputs. Learned controllers, compressed lookup tables, surrogate models of physical systems and certain perception components with structured outputs fit this description. In these settings, verification can provide assurance that testing cannot. For large perception networks and language models, network verification can play a supporting role — establishing robustness bounds, detecting specific failure modes, certifying components within a larger system — but it cannot carry the system's safety case. For those components, the assurance must come from the architecture around them: from checking their outputs, as in the previous chapters, and from constraining their actions at run time, which is the subject of the next. Chapter 8. Safety Envelopes: Runtime Assurance and Certification When a neural component cannot be verified and its outputs cannot be fully checked, there remains a third strategy, and it is the one that safety engineering has relied on longest. Accept that the complex component may fail, and build around it a simpler component that can be verified and that will prevent the failure from causing harm. The learned controller drives; a verified monitor watches, and takes over when the learned controller's actions would leave a region known to be safe. This chapter examines the architectures that implement this idea, the mathematics that underpins them, and the certification frameworks in aviation and automotive engineering that are beginning to codify them. The Simplex architecture The foundational design is the Simplex architecture, developed by Lui Sha and colleagues at the University of Illinois in the 1990s and described in Sha's 2001 paper "Using Simplicity to Control Complexity". Its original motivation had nothing to do with neural networks. Sha was concerned with how to upgrade control software in safety-critical systems — introducing a new, higher-performance controller whose correctness could not be fully established — without compromising safety. Simplex has three parts. A high-performance controller is complex, possibly unverified, and optimised for performance. A high-assurance controller is simple, conservative and verified; it may perform poorly, but it is guaranteed to keep the system safe. A decision module monitors the system's state and the high-performance controller's commands, and switches control to the high-assurance controller whenever continuing with the high-performance controller could lead the system outside a region from which the high-assurance controller can guarantee recovery. The critical concept is that region, often called the recoverable set. It is not enough to switch when the system becomes unsafe; by then it may be too late. The decision module must switch while the high-assurance controller can still bring the system back. Computing the recoverable set requires a model of the system's dynamics and of the high-assurance controller's capabilities, and the computation is done in advance, using control theory and formal methods, so that at run time the decision module need only check whether the current state, and the state that would result from the proposed command, remain within it. The architecture's elegance lies in where it places the verification burden. Only the decision module and the high-assurance controller need to be verified, and both are deliberately simple. The high-performance controller — which may be a deep neural network trained by reinforcement learning — need not be verified at all. Its failures are contained. Shields and safe reinforcement learning Reinforcement learning has a particular problem with safety, because it learns by trial and error. An agent that must explore to learn will, in the course of exploration, try actions that are dangerous. In simulation this does not matter; in the physical world it can be catastrophic. Shielding, introduced by Mohammed Alshiekh, Roderick Bloem, Rüdiger Ehlers, Bettina Könighofer, Scott Niekum and Ufuk Topcu in 2018, applies the Simplex idea to learning agents using techniques from formal methods. A safety specification is written in temporal logic — a formal language for statements about how a system's state evolves over time, such as "the robot never enters the restricted zone" or "whenever the pressure exceeds the threshold, the valve opens within two steps". From the specification and an abstract model of the environment, a shield is synthesised automatically: a small reactive system that, at each step, either passes the learning agent's chosen action through or replaces it with a safe alternative. Because the shield is synthesised from the specification, it is correct by construction with respect to the model. The agent can explore freely, and the shield guarantees that the specification is never violated — during learning and after. Shields can be placed before the agent, restricting the set of actions it may choose from, or after it, correcting its choices. In either position, the guarantee is relative to the abstract model of the environment. If the real environment behaves in ways the model does not capture, the guarantee does not hold. This is the recurring pattern: formal guarantees are always conditional on a model, and the engineering question is whether the model is conservative enough. Control barrier functions and reachability For continuous physical systems — vehicles, aircraft, robots — the mathematical tools for defining and enforcing safe regions come from control theory. Control barrier functions, developed extensively by Aaron Ames and colleagues from the mid-2010s, define a safe set as the region where a particular function of the state is non-negative, and derive a condition on the control input that guarantees the system never leaves that set. At each control step, a small optimisation problem finds the control input closest to the one the learned controller requested that still satisfies the barrier condition. If the learned controller's command is safe, it passes through unchanged; if not, it is minimally modified. The optimisation is fast enough to run in real time on embedded hardware. Reachability analysis computes, for a given dynamical system, the set of states it could reach from a given starting set under any admissible inputs and disturbances. Hamilton–Jacobi reachability, developed by Claire Tomlin and colleagues, computes these sets precisely for low-dimensional systems, and has been used to design safety monitors for aircraft and drones. Its cost grows rapidly with the number of state dimensions, which limits its direct use to small systems, though approximation techniques extend it. Both tools provide the recoverable set that Simplex requires and the safety filter that shields implement. Both are symbolic in the relevant sense: they produce guarantees from an explicit mathematical model, and their conclusions can be checked by anyone who has the model. Responsibility-sensitive safety A notable attempt to apply this thinking to automated driving is Responsibility-Sensitive Safety, proposed by Shai Shalev-Shwartz, Shaked Shammah and Amnon Shashua of Mobileye in 2017. RSS formalises common-sense rules of careful driving as mathematical conditions. It defines, for instance, a safe longitudinal distance — the minimum gap to a vehicle ahead such that, if the lead vehicle brakes as hard as it reasonably can, the following vehicle, after a stated response time, can brake and stop without collision. Similar definitions cover lateral distance, right of way and occluded areas. A vehicle that always maintains these conditions, and responds properly when another road user violates them, will never be the cause of a collision, under the model's assumptions about the dynamics and reasonable behaviour of others. RSS is intended as a safety layer above whatever planning system the vehicle uses, which may be neural. The planner proposes trajectories; RSS checks each against its formal rules and rejects or modifies those that would violate them. The IEEE 2846 standard, published in 2022, draws on this approach to define assumptions about road-user behaviour for use in automated driving safety models. RSS illustrates both the power and the limits of runtime assurance. Its rules are transparent and checkable. But its parameters — maximum reasonable braking, response times, accelerations — embody judgements about what other road users will do, and those judgements determine whether the guarantee is meaningful. Set too conservatively, the vehicle is unusably timid. Set too permissively, the guarantee is hollow. And RSS's correctness depends on the perception system correctly detecting other road users and estimating their positions and velocities. A safety layer that operates on perceived state inherits perception's errors. If the neural perception system fails to detect a pedestrian, RSS will not protect her. The perception problem, again This last point is the central difficulty for runtime assurance in systems with learned perception, and it deserves to be stated plainly. Simplex, shields, barrier functions and RSS all monitor the system's state. In a vehicle or robot, the state is estimated from sensors by perception components that are increasingly neural. If perception is wrong, the monitor monitors a fiction. Several mitigations are in use. One is sensor diversity: estimating critical quantities from independent sensors using independent methods — a neural camera pipeline and a classical radar or lidar pipeline, for instance — and treating disagreement as a hazard. Another is physical plausibility checking: verifying that the perceived state is consistent with physical laws and with its own history, the reverse check described in Chapter 4. A third is conservative fallback on uncertainty: if perception reports low confidence, or if its outputs fail plausibility checks, the monitor assumes the worst case within physical bounds. A fourth is operational design domain restriction: limiting operation to conditions — weather, lighting, road types, speeds — under which perception has been extensively validated, and having the system detect when it is leaving that domain. None of these makes perception verified. Together they make perception failures more likely to be detected and less likely to be catastrophic, which is the realistic goal. Certification frameworks The safety-critical industries have mature certification regimes developed for conventional software, and they are now working out how to accommodate learned components. The direction of travel is consistent across sectors and broadly aligned with the argument of this booklet: learned components are acceptable where the system architecture contains their failures, and the assurance argument must show how. In aviation, software is certified under DO-178C, published in 2011, which assigns software to design assurance levels according to the severity of the failures it could cause and requires correspondingly rigorous evidence. Its structure presumes that software requirements can be traced to code and that the code can be fully verified against them — presumptions that learned components violate. The European Union Aviation Safety Agency published an Artificial Intelligence Roadmap, updated as version 2.0 in 2023, and a series of concept papers giving guidance for machine-learning applications, which introduced the idea of "learning assurance" and classified AI applications by the level of human oversight retained. A joint committee of SAE International and EUROCAE, designated G-34 and WG-114, has been developing an aerospace standard for machine-learning development and certification. Early certification efforts concentrate on applications where a learned component assists rather than replaces a human or a conventional function, and where runtime monitoring can bound its effect. In automotive engineering, ISO 26262, first published in 2011 and revised in 2018, governs functional safety — hazards from malfunction of electrical and electronic systems. It was supplemented by ISO 21448, published in 2022, on the safety of the intended functionality (SOTIF), which addresses hazards that arise even when the system functions as designed but its design is insufficient — exactly the category into which neural perception errors fall. UL 4600, first published in 2020, sets out requirements for safety cases for autonomous products without a human driver. ISO/PAS 8800, published in December 2024, addresses safety of AI systems in road vehicles specifically, covering data, training, verification and the safety-related properties of AI components. At the level of general regulation, the European Union's Artificial Intelligence Act, adopted in 2024, classifies AI systems used as safety components of regulated products, or in certain sensitive domains such as medical devices and critical infrastructure, as high-risk, and requires risk management, data governance, technical documentation, logging, human oversight, and appropriate levels of accuracy, robustness and cybersecurity. Table 5 summarises the principal frameworks relevant to learned components in safety-critical systems. Table 5. Selected frameworks governing learned components in safety-critical systems. Framework Sector First published Relevance to learned components DO-178C Civil aviation software 2011 Baseline software assurance; ill-suited to learned components without supplement EASA AI Roadmap and concept papers Civil aviation Roadmap 2020; version 2.0 in 2023 Learning assurance; classification by level of human oversight ISO 26262 Road vehicles, functional safety 2011; revised 2018 Hazards from malfunction; assumes specifiable behaviour ISO 21448 (SOTIF) Road vehicles 2022 Hazards from insufficient specification, including perception limits UL 4600 Autonomous products 2020 Structured safety case for systems without human drivers ISO/PAS 8800 Road vehicles, AI 2024 Safety lifecycle for AI components EU AI Act Cross-sector regulation 2024 High-risk classification; robustness, oversight and documentation duties The assurance case The common thread in these frameworks is the assurance case or safety case: a structured argument, supported by evidence, that a system is acceptably safe for a given application in a given environment. Notations such as Goal Structuring Notation make the argument's structure explicit — a top-level claim decomposed into sub-claims, each supported by evidence or further argument, with assumptions and context stated. For a system containing a neural component, a credible assurance case almost never rests on the neural component being correct. It rests on a combination of arguments: that the component performs well within its validated domain, supported by testing evidence; that the system detects when it is outside that domain, supported by monitoring; that the component's failures within the domain are detected or contained by symbolic checks and runtime monitors, supported by formal verification of those monitors; and that the residual risk is acceptable, supported by analysis. The symbolic components are what make the argument possible. They are the parts of the system about which strong claims can be made and proved, and the architecture is arranged so that those strong claims are sufficient for safety even when the neural component's claims are weak. This is the practical meaning of the principle stated at the end of Chapter 1. Authority to commit belongs to the component whose behaviour can be verified. Runtime assurance is that principle applied to action rather than assertion, and certification frameworks are, slowly and unevenly, writing it into the rules. Chapter 9. Cases from Practice The patterns described so far are not only research proposals. Versions of them are in production in sectors where errors are expensive — medicine, law and public administration, financial services, cloud infrastructure — and some of those deployments predate the current interest in large language models by many years. This chapter works through cases from each sector. The aim is not to survey every deployment, which would be impossible and quickly out of date, but to show how the general principle takes concrete form under the constraints of a particular domain, and where it strains. A baseline: formal methods without neural networks It helps to begin with what symbolic methods alone can achieve when the problem is fully specifiable, because this sets the standard against which hybrid systems should be measured. Line 14 of the Paris Métro, opened in 1998 as the first fully automated line in the city's network, was controlled by safety-critical software developed using the B method, a formal development method created by Jean-Raymond Abrial. The safety requirements were stated formally, the software was refined step by step from abstract specification to executable code, and every refinement step was accompanied by proof obligations discharged by a combination of automated and interactive theorem proving. The development is widely reported to have produced well over a hundred thousand lines of code with no safety-related defects discovered after testing or in operation. The B method has since been used for numerous other railway signalling systems. This is what full formal methods buy: very high assurance, for a system whose behaviour can be completely specified in advance. The cost is substantial — specialist expertise, extensive proof effort, and the requirement that the problem be fully formalisable. A train-control system can be specified in terms of track segments, train positions, speeds and signals. It does not need to recognise a pedestrian in a camera image or understand a customer's question. As soon as such tasks are added, the specification can no longer be complete, and the question becomes how much of the B-method standard can be preserved for the parts that remain specifiable. Medicine: decision support with symbolic guard rails Clinical medicine has used rule-based decision support for decades. Electronic prescribing systems check orders against knowledge bases of drug–drug interactions, allergies, dose ranges and contraindications, and alert the prescriber when a rule fires. Standards exist for encoding clinical logic in shareable form: the Arden Syntax, first standardised in the early 1990s, represents medical logic modules as condition–action rules; the Clinical Quality Language, developed under HL7, expresses clinical criteria for quality measures and decision support in a precise, executable form; and the CDS Hooks specification allows external decision-support services to be invoked at points in the clinical workflow. These rule-based systems have well-known problems, and they are the problems of the first wave of symbolic AI. Their knowledge bases are expensive to maintain. Their rules are brittle: an interaction rule that ignores patient-specific factors fires when it is irrelevant. The result is alert fatigue: studies have repeatedly found that clinicians override the large majority of drug-interaction alerts, and that excessive alerting causes important warnings to be ignored along with trivial ones. A symbolic check that fires too often provides little effective protection. Neural systems are now entering clinical workflows in large numbers. Ambient documentation tools listen to consultations and draft clinical notes. Language models draft responses to patient messages, summarise records and suggest diagnoses. Imaging models flag findings for radiologists. Each of these introduces neural error into a domain where error is consequential, and the response emerging in well-designed deployments follows the pattern of this booklet. Consider ambient documentation. A neural model converts a recorded conversation into a draft note. The note's free-text narrative is reviewed and signed by the clinician, who carries responsibility for it; that is the primary safeguard, and it is a human rather than symbolic one. But the structured elements — coded diagnoses, medication orders, allergies, problem-list updates — can be checked symbolically before they reach the record. A diagnosis code proposed by the model can be validated against the terminology and checked for consistency with the patient's existing problems. A medication mentioned in the note can be checked against the interaction and allergy knowledge base. A dose can be checked against permissible ranges for the patient's age, weight and renal function. Where the model's output disagrees with what was said in the recording, a separate extraction can detect the discrepancy. These checks do not verify the note; they verify the parts of the note that can be verified, and they draw the clinician's attention to the parts that failed. Neural methods can also help with the symbolic layer's oldest problem. Alert fatigue arises because rules lack context. A learned model that estimates whether a particular alert is clinically relevant for a particular patient can prioritise alerts — showing the important ones prominently and suppressing the routine — while the underlying symbolic rule still fires and is logged. The design question is which component has authority. If the learned model can suppress a critical alert entirely, the system has given a neural network authority over a safety check, and a plausible-looking error can silently disable it. Careful designs allow the learned model to re-rank and to reduce the prominence of low-severity alerts, but never to suppress alerts above a defined severity, which remain under symbolic control. The general lesson from clinical deployments is that the symbolic layer's value depends heavily on its precision. A check that fires on every possible interaction is ignored; a check that fires only on clinically significant ones, defined by a curated and evidence-based knowledge base that takes patient factors into account, is heeded. Building such a knowledge base is the old knowledge acquisition problem, and there is no shortcut through it. Neural systems can help draft and maintain it, but the authority of the rules depends on human expert curation. Law and public administration: rules as code Law is the domain in which the gap between natural-language rules and formal logic is most consequential, and in which the case for formalisation is most contested. Many legal rules — eligibility for benefits, calculation of taxes, entitlement to leave — are essentially algorithms expressed in prose. Governments already implement them in software, and the software sometimes diverges from the law. The "rules as code" movement, promoted by governments including New Zealand's and by the Organisation for Economic Co-operation and Development's public-sector innovation unit in a 2020 report, argues that such rules should be drafted from the outset in both natural language and a formal, executable representation, so that the code is an authoritative expression of the law rather than an after-the-fact interpretation. Catala, a programming language designed by Denis Merigoux, Nicolas Chataing and Jonathan Protzenko and described in 2021, was built for this purpose. Its structure mirrors the way statutes are written, with general rules and exceptions that override them, so that each piece of code can be placed alongside the statutory text it implements and reviewed by lawyers and programmers together. Its creators applied it to parts of the French family-benefits rules and the US tax code, and found that the formalisation process surfaced ambiguities and inconsistencies in the source texts. Where do neural networks fit? Language models are increasingly used to answer questions about law and regulation — by lawyers, by citizens, by public servants. They are useful and they hallucinate, as Mata v. Avianca illustrated. A hybrid design for a benefits-eligibility assistant would use the language model to understand the citizen's description of their situation and to explain results in plain language, while the eligibility determination itself is made by executing the formalised rules on facts extracted from the conversation and confirmed by the citizen. The model never decides eligibility. It gathers facts, presents them for confirmation, and explains a result that the formal rules computed. This design inherits the strengths and limits of rules-as-code. Its strength is that eligibility decisions are made by an artefact that lawyers can review and that behaves identically for identical facts. Its limits are that formalisation of law involves interpretive choices — legal terms are often deliberately open-textured, leaving room for judgement in particular cases — and that a formal rule encodes one interpretation, which may later be overturned. Areas of law that depend heavily on standards such as "reasonable" or "in good faith" resist formalisation, and here a hybrid system should recognise that the question exceeds its formal rules and route it to a human. Formalisation suits the computational parts of law; it does not replace legal judgement. Financial services: scoring, rules and explanation Financial institutions have run hybrid systems for decades, often without calling them that. Fraud detection, anti-money-laundering monitoring and credit underwriting typically combine learned models with rule engines. In transaction monitoring, rules encode regulatory requirements and known typologies: transactions above certain thresholds must be reported, transfers to sanctioned parties must be blocked, patterns indicative of structuring must be flagged. These rules are explicit because regulators require that institutions be able to explain what they monitor and why. Learned models add detection of novel or subtle patterns that rules miss, scoring transactions by risk. The architecture places the regulatory rules in authority — a transaction that matches a sanctions list is blocked regardless of what any model says — and uses the learned model to prioritise investigation among the remainder. Sanctions screening itself relies on fuzzy matching of names, where learned models can reduce false positives, but the final block decision rests on rules and human review. In credit decisions, the explanatory requirement is sharper. In the United States, lenders that decline an applicant must state the principal reasons, under the Equal Credit Opportunity Act and its implementing Regulation B, and the Consumer Financial Protection Bureau has made clear that the use of complex algorithms does not relieve lenders of this duty. More broadly, banking supervisors expect institutions to manage model risk under guidance such as the US Federal Reserve's SR 11-7, issued in 2011, which requires validation, documentation and governance of models. Learned credit models are used, but often within constraints: monotonicity requirements, for instance, ensuring that an applicant's score never decreases when their income increases with everything else held fixed. Such constraints can be imposed during training and verified formally — monotonicity is a property that network verification methods can check — giving lenders and regulators assurance that the model's behaviour respects basic economic logic. Language models in financial services are being deployed for customer service, document analysis, research and compliance review. The hybrid response follows the familiar pattern. A model that answers customers' questions about their accounts retrieves their data from authoritative systems rather than recalling it, and its statements about balances, fees and terms are checked against the systems of record. A model that drafts compliance analyses has its regulatory citations validated against a regulatory database. A model that extracts terms from contracts has its extractions checked for internal consistency and against the contract's structure. Cloud infrastructure: automated reasoning at scale The most extensive industrial use of automated reasoning in recent years has been in cloud computing, and it has recently been extended to check neural outputs. Amazon Web Services began investing heavily in automated reasoning in the mid-2010s. A tool called Zelkova, described by John Backes and colleagues in 2018, translates access-control policies — the documents that determine who may access which cloud resources — into logical formulas and uses SMT solvers to answer questions about them, such as whether a policy allows access from anyone on the public internet. Zelkova underlies features that warn customers when storage buckets are publicly accessible, and it reportedly answers enormous numbers of such queries. The point is that SMT-based reasoning about real security policies was made fast and reliable enough to run continuously at very large scale. In December 2024 AWS previewed, and in August 2025 made generally available, a feature called Automated Reasoning checks within its Bedrock Guardrails service for applications built on language models. It is a direct commercial implementation of the generate-and-verify pattern described in Chapter 6. A customer uploads a natural-language policy document — an HR policy, a set of lending criteria, an operational procedure. The system extracts from it a formal policy consisting of variables and rules, which the customer reviews, tests and refines; test scenarios can be generated automatically, and advanced users can inspect the underlying logic in the standard SMT-LIB format. At run time, a language model's answer to a user's question is translated into logical assertions over the policy's variables, and a solver determines whether the answer is valid with respect to the policy, invalid because it contradicts the policy, or merely satisfiable because its truth depends on facts not stated. The system also flags translation ambiguity when the answer could be read more than one way. AWS's own documentation describes the feature as offering up to 99 percent verification accuracy. That figure should be read carefully, because it is a vendor claim without a published methodology, and because "verification accuracy" here depends on both the solver, which is sound, and the translations, which are performed by neural models and are not. The architecture is nonetheless instructive: the policy is formalised at design time with human review, the run-time translation is given a confidence threshold, and the result types distinguish between "contradicts the policy" and "not determined by the policy". These are exactly the design choices that separate a real guarantee from a cosmetic one. What the cases share Across these sectors, several regularities appear. First, the symbolic layer almost always encodes something that already existed in explicit form: a regulation, a policy, a clinical guideline, a drug knowledge base, a terminology. Neuro-symbolic systems succeed most readily where an organisation's rules are already written down and maintained. Where the rules are tacit, the symbolic layer must first be built, and this is often the dominant cost. Second, authority is allocated explicitly. In the well-designed systems, there are decisions the neural component is not permitted to make: blocking a sanctioned transaction, suppressing a critical drug alert, determining legal eligibility. The neural component contributes to these decisions — by extracting facts, ranking alternatives, explaining outcomes — but does not make them. Third, the translation step between natural language and formal representation is where the remaining risk concentrates, and the best systems move as much translation as possible from run time to design time, where humans can review it. Fourth, the symbolic checks are scoped and reported. They do not claim to verify everything. They state what they checked, against which version of which rules, and what remained unchecked. The value of the symbolic layer depends on this honesty. And fifth, in every case, the hybrid system is more conservative than an unconstrained neural system would be. It answers fewer questions, refuses more, escalates more often. In each of these sectors, that is regarded as the right trade, because the cost of a confident error exceeds the cost of a declined answer. The next chapter considers what this trade costs and where the hybrid approach falls short. Chapter 10. Limits, Costs and Honest Objections An argument for a technical approach is only as credible as its account of where the approach fails. Neuro-symbolic integration has real limitations, some of them inherited from the symbolic tradition, some arising from the integration itself, and some that no method can overcome. Practitioners who adopt hybrid architectures without understanding these limits risk building systems that are more expensive, less useful and not much safer than the neural systems they replaced — or, worse, systems whose formal components lend unearned confidence to the whole. This chapter sets out the strongest objections and assesses each. The specification bottleneck The most fundamental limit has appeared in every chapter: a symbolic check can only enforce what has been specified, and specifying is hard. The difficulty has several layers. The first is coverage. A rule base encodes the constraints its authors thought of. Safety-critical failures frequently arise from situations nobody anticipated, and an unanticipated situation is, by definition, one for which no rule was written. A symbolic layer catches violations of known constraints; it is silent about unknown ones. This is the brittleness of expert systems in modern form. The second is correctness. Specifications contain errors, and formal specifications contain formal errors, which are no less wrong for being precise. Experience in formal methods has shown repeatedly that the specification is where many of the bugs are. A system verified against a wrong specification is reliably wrong. Worse, because the specification is the standard against which correctness is judged, its errors are invisible to the verification process. Only an independent check — testing against reality, expert review, operational experience — can find them. The third is expressibility. Some properties resist formal statement entirely. "The summary should be faithful to the source." "The response should be appropriate for a distressed patient." "The trajectory should be comfortable for passengers." These are real requirements, and in many applications they are the requirements that matter most. They can be approximated by formal proxies — the summary should contain no named entity absent from the source; the response should not contain certain phrases; lateral acceleration should stay below a threshold — but the proxies are not the requirement, and a system optimised to satisfy the proxy can fail the requirement. This is a version of Goodhart's law: a measure that becomes a target ceases to be a good measure. The honest response to the specification bottleneck is not to pretend it away but to make it visible. Every symbolic check should be documented with its scope: what it checks, what it does not, and on what assumptions it relies. Assurance cases should identify the properties that are formally checked, those supported only by testing, and those supported only by human judgement. A system that makes these distinctions clearly is much safer than one that blurs them, even if both contain the same checks. The cost of knowledge Building and maintaining symbolic knowledge is expensive, and its cost does not decline with scale the way the cost of neural capability has. A large language model's knowledge improves when it is retrained on more data, and the marginal cost of covering a new topic is small. A curated ontology or rule base improves only when experts add to it, and each addition must be reviewed, tested and reconciled with what already exists. The major biomedical ontologies are maintained by dedicated organisations with permanent staff, editorial processes and regular release cycles. An enterprise that builds a knowledge graph to ground its language-model applications takes on a comparable obligation in proportion to its scope. Neural methods can reduce this cost. Language models are effective at drafting rules from documents, proposing ontology extensions, suggesting mappings between vocabularies and identifying likely errors. Commercial tools now offer automatic extraction of formal policies from natural-language documents. But each of these uses places a neural model in the process that produces the symbolic layer, and the symbolic layer's authority depends on its being correct. If machine-drafted rules are accepted without careful review, the symbolic layer acquires neural errors, and the guarantee it was supposed to provide is compromised at the source. The cost of human review cannot be eliminated without eliminating the point of having the symbolic layer. The economic consequence is that neuro-symbolic integration is most cost-effective where explicit knowledge already exists and is already maintained — in regulated domains where rules are published, in organisations with formal policies, in fields with mature terminologies. It is least cost-effective where knowledge is tacit, fast-changing or contested. This is not a reason to avoid hybrid methods, but it is a reason to choose their scope carefully, starting with the constraints that are both most consequential and most readily formalised. The translation seam Chapter 6 identified the translation between natural language and formal representation as the weak point of reasoning verification, and Chapter 5 identified the analogous extraction gap in grounding. This seam deserves emphasis as a general limitation, because it is where the neural network's unreliability re-enters a system designed to contain it. In most practical hybrid systems, some neural component translates between the world of natural language, images or sensor data and the world of symbols. The symbolic component's guarantee holds only relative to the symbols it receives. If the translation is wrong, the guarantee holds for a problem other than the one that was posed. And the translation errors that matter most are the subtle ones — a missed qualifier, a misread negation, a wrong unit — because gross errors are usually caught by type checks or plausibility tests. There is no complete solution, but several partial ones compound. Translations can be constrained to restricted formats that leave less room for error. They can be performed multiple times independently and checked for agreement. They can be round-tripped. Key extracted facts can be shown to a human for confirmation before the symbolic layer acts on them, which turns an unverified neural translation into a human-verified one at modest cost. And the system can be designed so that the most consequential translations — of rules, policies and specifications — happen once, at design time, under expert review, leaving only the translation of case facts at run time. False confidence A more insidious risk is that symbolic components make hybrid systems look safer than they are. The language of formal methods carries authority. A system described as "formally verified" or "mathematically guaranteed" invites trust, and that trust is often extended beyond the scope of what was actually verified. A user told that an answer was "verified by automated reasoning" may not know that the verification covered only consistency with a particular policy, given a particular translation of the answer, and said nothing about whether the policy applied to their situation. An engineer told that a network is "certified robust" may not know that the certificate covers only small perturbations around specific test points. This is a social and organisational risk as much as a technical one, and it has precedents. Automation bias — the tendency of people to over-rely on automated systems and to stop checking their outputs — is well documented in aviation and medicine. A verification badge can amplify it. The mitigation is discipline in language and interface design: always report the scope of a verification alongside its result; never use unqualified words like "verified", "guaranteed" or "proven" in user-facing contexts; and design workflows so that human reviewers check the things the symbolic layer does not. When neural methods simply win The strongest objection to neuro-symbolic integration comes from the history of the field itself. Repeatedly, tasks that were thought to require explicit symbolic structure turned out to be learnable by sufficiently large neural networks trained on sufficient data. Machine translation, once pursued through hand-built grammars, was transformed by neural networks. Game playing, once the showcase of symbolic search, was conquered by systems in which learning did most of the work. Mathematical olympiad problems, which a hybrid system first approached through formal proof, were then solved at a higher level by a system working in natural language. The computer scientist Richard Sutton summarised this pattern in a widely read 2019 essay, "The Bitter Lesson": in the long run, general methods that leverage computation outperform methods that build in human knowledge. This objection has force against one version of the neuro-symbolic argument: the claim that symbolic structure is necessary for capability. That claim has a poor track record, and this booklet does not make it. The argument here is about assurance, not capability. Even if a neural system becomes as capable as any symbolic one at a task, the need for independent verification remains when errors are costly. Human experts are extremely capable, and safety-critical industries still require their work to be checked, documented and constrained by explicit procedures. The bitter lesson is about how to build the most capable system; it says nothing about how to know when a capable system is wrong. There is, however, a softer form of the objection that should be taken seriously. As neural systems improve, the marginal safety benefit of symbolic checks may decline, while their costs — in maintenance, rigidity and lost helpfulness — remain. At some point, a symbolic check that rarely catches anything and frequently blocks legitimate outputs may cost more than it saves. This is an empirical question that must be answered domain by domain, by measuring how often the checks catch real errors and how often they block correct outputs. Systems should be instrumented to collect exactly this evidence, so that the case for each check can be revisited as the neural components change. Rigidity and over-refusal A related cost is that symbolic layers make systems rigid. A rule engine that blocks every output it cannot confirm will block many correct outputs that fall outside its coverage. In consumer applications this degrades the experience; in professional applications it can push users to work around the system entirely, at which point its safety benefits vanish. Clinicians who override most alerts, and analysts who export data to an unconstrained tool because the constrained one refuses too often, are examples of the same phenomenon. The design response is graduated authority. Not every check needs to be a hard block. Checks on the most consequential constraints — those whose violation could cause serious, irreversible harm — should block. Checks on less consequential constraints can warn, annotate, or route to human review. Outputs that the symbolic layer can neither confirm nor refute can be presented with clear marking of their unverified status rather than suppressed. Getting this calibration right is the main practical skill in building hybrid systems that people actually use. Problems neither tradition solves Finally, some problems lie outside the reach of either neural or symbolic methods and should not be presented as solved by their combination. Neuro-symbolic integration does not resolve disagreements about values. A formal policy encodes someone's judgement about what the system should do; it does not make that judgement correct, fair or legitimate. Encoding a biased lending rule in formal logic makes it precisely and reliably biased. Neither does integration solve the problem of novel situations. A symbolic layer can detect that an input falls outside its known categories, which is valuable, but it cannot determine the right response to a genuinely new situation. That requires judgement, which in safety-critical systems should remain with accountable humans. And integration does not eliminate the need for empirical validation. Formal guarantees are conditional on models and specifications, and the only way to learn whether those models and specifications match reality is to test against reality and to learn from operational experience. A hybrid system still needs field data, incident reporting and continuous monitoring. The symbolic layer makes the system's assumptions explicit; it is the operational record that shows whether those assumptions hold. None of these limits undermines the core argument. They define its scope. Neuro-symbolic integration provides strong, checkable guarantees for the parts of a system's behaviour that can be specified, and makes explicit the boundary beyond which such guarantees run out. That is less than a complete solution to AI safety, and considerably more than the neural alternative offers. The final chapter turns these lessons into a method. Chapter 11. A Design Discipline for Hybrid Systems The preceding chapters have described techniques, cases and limits. This chapter assembles them into a method: a sequence of decisions that a team building a safety-critical system with neural components should work through. It is not a substitute for the domain-specific standards that govern particular industries, and it does not prescribe tools. It describes the questions that, in the experience reflected throughout this booklet, separate hybrid systems that deliver real assurance from those that merely contain symbolic components. Step one: identify what must never happen Begin not with the model's capabilities but with the hazards. What outputs or actions would cause serious harm? For a medication assistant: recommending a contraindicated drug, a dose outside the safe range, a combination with a dangerous interaction. For a vehicle: a trajectory that leads to collision, leaving the drivable area, violating right of way. For a benefits assistant: telling an eligible person they are ineligible, or the reverse, in a way that causes them to act on it. For a financial agent: executing an unauthorised transaction, breaching a regulatory limit, disclosing a customer's data to another. This list is the foundation of everything that follows. Established hazard-analysis techniques — failure modes and effects analysis, fault tree analysis, and the systems-theoretic process analysis developed by Nancy Leveson — apply directly, and they should be applied to the system as a whole, including the neural components, the symbolic components and the human operators. The result should be a set of hazards ranked by severity and a set of safety constraints, each stating what the system must do or must not do to prevent a hazard. The constraints will fall into categories. Some can be stated precisely in terms of quantities the system has access to: the dose must be within this range for this patient's weight and renal function; the distance to the vehicle ahead must exceed this function of the two speeds. Some can be stated precisely but depend on facts that must be perceived or extracted: the patient must not be allergic to this drug, which requires knowing the patient's allergies. Some cannot be stated precisely at all: the explanation must be accurate and not misleading. This classification determines what kind of assurance is available for each constraint. Step two: allocate authority For each constraint, decide which component has authority over it. The principle is that a constraint that can be precisely stated should be enforced by a component whose behaviour can be verified, and that component must be positioned so that the neural component cannot bypass it. In practice, this means drawing an explicit assertion boundary — the point in the architecture at which outputs become commitments: displayed to a user as fact, written to a record, sent as a command to an actuator, executed as a transaction. Everything that crosses the assertion boundary must pass through the symbolic checks for the constraints that apply to it. Nothing crosses by any other route. This sounds obvious, but violations are common. An agentic system in which the language model can call a database-write tool directly has placed the assertion boundary inside the model. A clinical system in which the model's draft is displayed to the patient before the interaction check completes has a gap. A vehicle in which the learned planner's commands go to the actuators by one path and the safety monitor's override by another, with a race between them, has an ambiguous boundary. The architecture should make it structurally impossible for an unchecked output to become a commitment, not merely unlikely. For constraints that cannot be precisely stated, authority should usually rest with a human, supported by the system. The design question is how to present the neural output and the results of whatever partial checks are available so that the human can exercise judgement effectively, rather than rubber-stamping. Step three: choose formalisms to fit the constraints For each precisely statable constraint, select the least expressive formalism that captures it, following the trade-offs set out in Chapter 3. Arithmetic bounds and simple logical conditions belong in straightforward code or an SMT solver. Class hierarchies and terminological constraints belong in a description-logic ontology. Large sets of rules over relational data belong in Datalog. Regulations with defaults and exceptions may suit answer set programming or a purpose-built rules language. Properties of dynamic behaviour over time belong in temporal logic and runtime monitors. Proof-carrying outputs, where a model generates an artefact whose correctness should be established mathematically, belong in a proof assistant or a program verifier. Resist the temptation to adopt a single, maximally expressive formalism for everything. It will make the easy checks slow, the hard checks incomplete, and the whole layer harder to review. At the same time, resist the temptation to implement checks in ad hoc code when a formalism with clear semantics is available. A hand-written function that checks drug classes by string matching will eventually disagree with the terminology it is supposed to implement. Code with formal semantics, executed by a well-tested engine, can be reviewed and reasoned about in a way that ad hoc code cannot. Step four: own the translations Every point at which information passes between the neural and symbolic worlds is a point of risk. List them: the extraction of facts from text, the linking of mentions to ontology identifiers, the translation of questions into queries, the translation of answers into assertions, the perception of state from sensors. For each, decide how errors will be detected. The techniques available have been described: constrained output formats that eliminate free text; independent repeated translation with agreement checks; round-trip back-translation; consistency checks against known constraints; confirmation by a human of key extracted facts; and, for perception, sensor diversity and physical plausibility checks. Select those appropriate to the severity of the constraint the translation feeds. A translation that determines whether a drug is administered warrants human confirmation. A translation that determines the order in which search results are shown does not. Above all, move translations to design time where possible. The rules, policies and specifications that the symbolic layer enforces should be formalised once, with neural assistance if helpful, reviewed by domain experts, tested against cases with known answers including automatically generated boundary cases, versioned and placed under change control. Run-time translation should be confined to the facts of the individual case. Step five: decide what happens on rejection A symbolic check that rejects an output must lead somewhere. The options are limited and each has costs. The system can ask the neural component to try again, feeding back the reason for rejection; this is effective for recoverable errors but can loop, and a cap on retries is needed. It can fall back to a conservative default — the high-assurance controller in a Simplex design, a templated answer, a refusal. It can escalate to a human. Or it can present the output with a clear marking that it failed the check, for a human to adjudicate. The choice should be made per constraint and documented, and the fallback behaviour should itself be verified. A fallback that is less safe than the rejected output — an emergency stop on a motorway, a refusal to provide any information to a patient in urgent need — is a hazard in its own right, and must appear in the hazard analysis. Step six: handle the undetermined case Most symbolic checks have three outcomes, not two: the output is confirmed, the output is contradicted, or the output cannot be determined either way — because the knowledge base lacks the relevant facts, the solver timed out, the extraction failed, or the formal rules do not settle the matter. The third outcome is where designs most often go wrong, usually by silently treating "undetermined" as "confirmed". The handling of undetermined outputs should depend on severity. For the most consequential constraints, undetermined should be treated as rejection. For lesser ones, it can be treated as a warning, with the output presented and its unverified status made visible. In all cases, the frequency of undetermined outcomes should be monitored, because a rising rate indicates that the system is operating outside the coverage of its symbolic layer — a signal of drift in the input distribution, a gap in the knowledge base, or a change in the neural component's behaviour. Step seven: report scope, not just results Every output that has passed symbolic checks should carry, at least in its logged form and where appropriate in its user-facing form, a record of what was checked. Which constraints were evaluated, against which version of which rules or knowledge base, using which extracted facts, with which result. Which constraints were not evaluated, and why. This record serves three purposes. It allows users to judge whether the checks cover what they need. It allows auditors and investigators to reconstruct, after an incident, exactly what the system knew and did. And it makes the boundary of assurance visible to the people who build and operate the system, so that they do not mistake partial checking for complete checking. Step eight: build the assurance case and test it against reality Assemble the results of the previous steps into a structured argument that the system is acceptably safe for its intended use. The argument should make explicit which claims are supported by formal verification, which by testing, which by operational experience and which by human oversight. It should state its assumptions: the operational domain, the correctness of the knowledge base, the accuracy of perception within that domain. Then test the assumptions. Formal verification establishes that components meet their specifications; only testing in realistic conditions establishes that the specifications are adequate. Red-teaming — deliberate attempts to make the system fail — should target the seams: the translations, the undetermined cases, the boundaries of the knowledge base and the operational domain. Every failure found should lead to a change in specification, knowledge, architecture or operating procedure, and the assurance case should be updated. After deployment, instrument the system to record how often each check fires, how often its rejections are confirmed as correct by later review, how often undetermined outcomes occur and how often humans override the system. This operational evidence is what allows the assurance case to be maintained over time, and what allows the team to decide, on evidence rather than intuition, whether a particular check is still earning its cost. A worked example: a mortgage-policy assistant To see the steps together, consider a bank that wants a language-model assistant to help its loan officers answer questions about the bank's residential mortgage policy: maximum loan-to-value ratios, debt-to-income limits, documentation requirements, exceptions and the authority levels needed to approve them. The policy runs to a hundred pages and is revised several times a year. The hazard analysis identifies what must never happen. The assistant must not tell an officer that a loan is within policy when it is not, because the officer may approve it on that basis, exposing the bank to credit loss and regulatory sanction. It must not cite a policy provision that does not exist or has been superseded. It must not state an approval authority lower than the policy requires. Less severe, but still important: it should not tell an officer a compliant loan is non-compliant, which would cost business and erode trust in the tool. Authority is allocated accordingly. The determination of whether a described loan is within policy belongs to a formal rule set, not to the model. The model's role is to understand the officer's question, extract the loan parameters, retrieve relevant policy text, and explain the result. The assertion boundary is the response shown to the officer; any statement in it about compliance, limits or authority levels must have passed the formal check. The formalism is chosen to fit. The policy's quantitative limits — ratios, thresholds, tiers depending on property type and borrower category — are arithmetic constraints with logical conditions, well suited to an SMT encoding. Its exceptions, which override general limits in specified circumstances and require specified approval levels, fit a rules language with explicit precedence. Both are formalised at design time. A language model drafts the formal rules from the policy document; the bank's credit-policy team reviews each rule against the source text, side by side; and a test suite of several hundred loan scenarios with known correct outcomes, including automatically generated scenarios sitting exactly on every threshold, is run against the formalisation before it is approved. The formal rules are versioned in step with the policy document, and a policy revision cannot be published without a corresponding formalisation revision. The translations are owned. At run time, the model extracts loan parameters from the officer's question into a fixed structured form. The extracted parameters are shown back to the officer — "I have understood: owner-occupied property, loan amount X, valuation Y, borrower income Z" — and the officer confirms or corrects them before the check runs. The model's draft answer is then parsed into assertions about compliance and authority, which the solver checks against the rules and the confirmed facts. Rejection and the undetermined case are handled explicitly. If the model's draft asserts compliance and the solver finds a contradiction, the draft is discarded, and the response is assembled from the solver's result — which rule is violated and by how much — with the model allowed only to phrase it. If the solver finds the answer undetermined, because the question involves a factor the formal rules do not cover, the response says so plainly, quotes the relevant policy text, and directs the officer to the credit-policy team. Scope is reported. Each response records the policy version, the confirmed facts and the rules evaluated, and the officer sees a short line stating which policy version the answer was checked against. Operational monitoring records how often the model's drafts were contradicted by the solver — an indicator of where the model is unreliable — and how often questions fell outside the formal rules, which indicates where the formalisation needs extending. Nothing in this design makes the assistant infallible. The credit-policy team's formalisation could misread a provision; the officer could confirm a wrongly extracted fact without reading it. But each of these failure routes is identified, narrow and auditable, and the failure that would otherwise be most likely — a fluent, confident and wrong statement of compliance — has been removed from the system's repertoire. A checklist of warning signs Teams reviewing an existing or proposed hybrid system can use the following questions as a quick diagnostic. Any "no" or "unclear" deserves attention. Is there a single, clearly defined assertion boundary, and is it structurally impossible for an unchecked output to cross it? Does the neural component lack any means to bypass, disable or skip the symbolic checks? Are the rules and knowledge the symbolic layer enforces reviewed by domain experts, versioned and under change control? Are run-time translations between natural language and formal representation checked by some independent means? Is the "undetermined" outcome handled explicitly, and is its frequency monitored? Does every verified output carry a record of what was and was not checked? Are user-facing claims of verification qualified by their scope? Are fallback behaviours themselves included in the hazard analysis? Is there operational evidence that the checks catch real errors at an acceptable cost in false rejections? None of these questions is about which neural model or which solver was chosen. They are about architecture, process and honesty. That is where the difference between real and nominal assurance lies. Conclusion. Where Authority Should Live The question that opened this booklet was how to make neural networks safe enough for settings where their errors cause harm. The answer it has defended is that the question is subtly misposed. Neural networks cannot be made safe in that sense on their own, because they have no internal criterion that distinguishes their correct outputs from their plausible ones. What can be made safe is a system in which a neural network operates, provided the system is built so that the network's outputs become commitments only after passing through components whose behaviour can be stated and checked. The network proposes; logic disposes. Having followed the argument through grounding, reasoning verification, network verification, runtime assurance, practical cases and honest limits, several conclusions can be drawn that were not available at the start. What follows The first is that the important design decision in a hybrid system is not the choice of neural model or solver but the location of authority. A system with an excellent theorem prover that the language model may choose not to call provides no guarantee. A system with a modest rule engine that every output must pass provides a real one, within the rules' scope. When evaluating any system described as neuro-symbolic, the first question should be: what can the neural component do that the symbolic component cannot prevent? If the answer includes anything on the hazard list, the integration is incomplete. The second is that the value of symbolic methods in this setting lies less in their reasoning power than in their honesty about assumptions. Every symbolic guarantee examined in these chapters was conditional: on the knowledge base being correct, on the translation being faithful, on the physical model being conservative, on the specification being adequate. Neural reliability is conditional too, but its conditions cannot be enumerated. Symbolic guarantees can be wrong, but they can be wrong only in ways that were written down, which means they can be reviewed, tested and contested by people who did not build the system. This makes symbolic components the natural carriers of accountability in systems that must answer to regulators, courts, patients and the public. The third is that the seam between the neural and symbolic worlds — the translation of language and perception into symbols — is where the residual risk concentrates, and that most of the craft of building these systems lies in managing it. Moving translations to design time, where experts can review them; confirming key run-time translations with humans; checking translations against each other and against constraints: these unglamorous practices determine whether a hybrid system's guarantees are real. They receive far less attention in research than new integration architectures, and they deserve far more. The fourth is that the case for hybrid systems does not depend on neural networks being weak. The striking capability gains of recent years have strengthened, not weakened, the argument. As neural systems are entrusted with more consequential tasks, the cost of their unflagged errors rises, and so does the value of independent checking. A highly capable system that is occasionally and invisibly wrong is more dangerous in a safety-critical role than a less capable one, because people will rely on it more. The asymmetry between finding and checking means that capability gains on the generating side can be absorbed without any loss of assurance on the checking side — a more capable generator simply fails the check less often. What remains unsettled Several questions are genuinely open. The most important is how far the specification bottleneck can be eased. If neural systems become reliable enough at drafting formal rules from natural-language policy, and verification of the drafts becomes cheap enough, the cost of building symbolic layers could fall dramatically, and hybrid architectures could spread to domains where they are currently uneconomic. But the review step cannot be removed without undermining the point, and how much of it can be made efficient — through better tools for comparing formal rules with source text, through automated generation of test cases for expert adjudication — is an empirical question still being answered. A second open question concerns the properties that resist formalisation entirely: faithfulness, appropriateness, fairness, helpfulness. Partial formal proxies exist for each, and progress in interpretability research may eventually allow some properties of a network's internal computation to be checked directly. For now, these properties are assured, if at all, by testing and human judgement, and hybrid systems should be explicit that their formal guarantees do not extend to them. A third concerns certification. Aviation, automotive and medical-device regulators are working out how to certify systems with learned components, and the frameworks emerging are broadly consistent with the architecture this booklet has described: containment of learned components by verified monitors, explicit operational domains, structured assurance cases. But the standards are young, practice varies, and the questions of how much evidence is enough, and of what kind, are unsettled. What to do differently For people who build or govern AI systems in consequential settings, the practical upshot can be stated in a few sentences. Stop asking whether a model is accurate enough and start asking what the system does when the model is wrong. Write down the outcomes that must never happen, and for each one, identify the component that prevents it and confirm that the model cannot route around that component. Treat the rules, ontologies and specifications that symbolic components enforce as safety-critical artefacts in their own right, with expert review, testing, versioning and change control. Invest in the translations between language and logic as seriously as in the model and the solver. Report the scope of every check alongside its result, and never let the word "verified" travel without its qualifications. And measure, in operation, what the checks catch and what they cost, so that the design can improve on evidence. None of this is exotic. It is the discipline that safety engineering has applied to complex systems for decades, extended to a new kind of component whose distinctive property is that it is powerful, useful and incapable of knowing when it is wrong. Neural networks have given machines something like intuition. Formal logic, joined to them with care, gives the rest of us a way to hold that intuition to account. Glossary Abstract interpretation. A framework for sound static analysis that computes over-approximations of the values a program, or a neural network, can produce, so that properties proved for the approximation hold for the real system. Assertion boundary. The point in a system's architecture at which outputs become commitments — shown to a user as fact, written to a record, or sent to an actuator. In a well-designed hybrid system, every output crossing it has passed the relevant symbolic checks. Assurance case. A structured argument, supported by evidence, that a system is acceptably safe or reliable for a stated use in a stated environment. Also called a safety case. Autoformalisation. The translation of natural-language statements, rules or problems into a formal logical representation, increasingly performed by language models. Closed-world assumption. The convention that any fact not stated or derivable is false. Used by databases and Datalog. Complete (proof system or verifier). Able to derive every valid conclusion, or, for a verifier, to decide every property given enough time. Constrained decoding. Restricting a language model's generation, token by token, so that its output conforms to a formal grammar, schema or other constraint. Control barrier function. A mathematical function defining a safe set of states for a dynamical system, used to derive control inputs that keep the system within that set. Description logic. A family of decidable fragments of first-order logic designed for representing concepts, relations and taxonomies; the basis of the OWL ontology language. Hallucination. The generation by a neural model of fluent, plausible output that is false or unsupported by its sources. Knowledge graph. A large collection of facts represented as entities connected by typed relations, often structured according to an ontology. Ontology. A formal specification of the concepts in a domain and the logical relationships among them, with axioms from which further facts can be derived. Open-world assumption. The convention that a fact not stated is unknown rather than false. Used by ontology languages such as OWL. Runtime assurance. An architecture in which a verified monitor watches an unverified component during operation and intervenes, typically by switching to a verified fallback, when continuing would risk leaving a safe region. Shield. A small reactive component, synthesised from a formal safety specification, that blocks or corrects unsafe actions of a learning agent. Simplex architecture. A runtime assurance design combining a high-performance controller, a simple verified high-assurance controller and a decision module that switches between them. SMT (satisfiability modulo theories). Automated reasoning that extends Boolean satisfiability with built-in theories such as arithmetic, arrays and strings; implemented by solvers such as Z3 and cvc5. Sound (proof system or verifier). Never deriving a false conclusion from true premises; for a verifier, never certifying a property that does not hold. Symbol grounding problem. The question, posed by Stevan Harnad, of how the symbols in a formal system can acquire meaning intrinsic to the system rather than borrowed from a human interpreter. Trusted kernel. The small core of a proof assistant that checks every proof against the logic's basic rules; only it, not the process that found the proof, needs to be trusted. Further Reading The works below are the principal sources drawn on in the text, with a note on what each offers. They are grouped by theme. Foundations and the integration debate Henry Kautz, "The Third AI Summer", AI Magazine 43(1), 2022. The written version of Kautz's 2020 Engelmore lecture, with the six-category taxonomy of neuro-symbolic integration used in Chapter 4. A clear, opinionated overview of where the field stood at the start of the current wave. Artur d'Avila Garcez and Luís C. Lamb, "Neurosymbolic AI: The 3rd Wave", Artificial Intelligence Review, 2023. A survey and position paper by two of the longest-standing researchers in the area, arguing that integration is needed for robust, explainable learning. Gary Marcus, "The Next Decade in AI: Four Steps Towards Robust Artificial Intelligence", 2020. The fullest statement of the case that deep learning needs symbolic supplementation, written shortly after the Montreal debate with Yoshua Bengio. Stevan Harnad, "The Symbol Grounding Problem", Physica D 42, 1990. The classic statement of the problem of how formal symbols acquire meaning. Richard Sutton, "The Bitter Lesson", 2019. A short essay arguing that general learning methods eventually beat built-in human knowledge; the strongest compact form of the objection discussed in Chapter 10. Hallucination Adam Tauman Kalai and Santosh S. Vempala, "Calibrated Language Models Must Hallucinate", Proceedings of the 56th ACM Symposium on Theory of Computing, 2024. The statistical argument that calibrated models must generate falsehoods on rarely seen facts. Adam Tauman Kalai, Ofir Nachum, Santosh S. Vempala and Edwin Zhang, "Why Language Models Hallucinate", 2025. Extends the statistical argument and identifies evaluation incentives that reward guessing over abstention. Ziwei Ji and colleagues, "Survey of Hallucination in Natural Language Generation", ACM Computing Surveys, 2023. A broad survey of definitions, causes, measurement and mitigation. Logic, ontologies and reasoning tools Franz Baader, Ian Horrocks, Carsten Lutz and Uli Sattler, An Introduction to Description Logic, Cambridge University Press, 2017. The standard textbook on the logics underlying OWL and large biomedical ontologies. Daniel Kroening and Ofer Strichman, Decision Procedures: An Algorithmic Point of View, 2nd edition, Springer, 2016. An accessible technical introduction to SAT and SMT solving. Leonardo de Moura and Nikolaj Bjørner, "Z3: An Efficient SMT Solver", TACAS, 2008. The paper introducing the most widely used SMT solver. Integration architectures Robin Manhaeve and colleagues, "DeepProbLog: Neural Probabilistic Logic Programming", NeurIPS, 2018. Introduces neural predicates in a probabilistic logic programming language. Jingyi Xu, Zilu Zhang, Tal Friedman, Yitao Liang and Guy Van den Broeck, "A Semantic Loss Function for Deep Learning with Symbolic Knowledge", ICML, 2018. A principled method for training networks against logical constraints. Samy Badreddine, Artur d'Avila Garcez, Luciano Serafini and Michael Spranger, "Logic Tensor Networks", Artificial Intelligence 303, 2022. The developed form of the fuzzy-logic approach to differentiable reasoning. Jiayuan Mao and colleagues, "The Neuro-Symbolic Concept Learner", ICLR, 2019. A representative perception-then-reasoning pipeline. Reasoning verification and mathematics Trieu H. Trinh, Yuhuai Wu, Quoc V. Le, He He and Thang Luong, "Solving Olympiad Geometry without Human Demonstrations", Nature 625, 2024. The AlphaGeometry paper, a clear example of a neural proposer paired with a symbolic deduction engine. Liangming Pan and colleagues, "Logic-LM: Empowering Large Language Models with Symbolic Solvers for Faithful Logical Reasoning", Findings of EMNLP, 2023. Translation of reasoning problems into solver input, with error-driven self-repair. Luyu Gao and colleagues, "PAL: Program-Aided Language Models", ICML, 2023. Delegation of computation from language models to an interpreter. Verifying neural networks Guy Katz, Clark Barrett, David Dill, Kyle Julian and Mykel Kochenderfer, "Reluplex: An Efficient SMT Solver for Verifying Deep Neural Networks", CAV, 2017. The paper that established practical verification of neural networks, using the ACAS Xu case. Changliu Liu and colleagues, "Algorithms for Verifying Deep Neural Networks", Foundations and Trends in Optimization, 2021. A systematic survey of complete and incomplete verification methods. Jeremy Cohen, Elan Rosenfeld and Zico Kolter, "Certified Adversarial Robustness via Randomized Smoothing", ICML, 2019. The standard reference for probabilistic robustness certificates. Runtime assurance and certification Lui Sha, "Using Simplicity to Control Complexity", IEEE Software 18(4), 2001. The Simplex architecture. Mohammed Alshiekh and colleagues, "Safe Reinforcement Learning via Shielding", AAAI, 2018. Formal synthesis of shields for learning agents. Shai Shalev-Shwartz, Shaked Shammah and Amnon Shashua, "On a Formal Model of Safe and Scalable Self-Driving Cars", 2017. The Responsibility-Sensitive Safety model. Nancy Leveson, Engineering a Safer World: Systems Thinking Applied to Safety, MIT Press, 2011. The systems-theoretic approach to hazard analysis recommended in Chapter 11; essential reading for anyone designing safety-critical systems with complex components. European Union Aviation Safety Agency, Artificial Intelligence Roadmap 2.0, 2023, and associated concept papers on machine-learning applications. The most developed regulatory thinking on certifying learned components in aviation. Practice Denis Merigoux, Nicolas Chataing and Jonathan Protzenko, "Catala: A Programming Language for the Law", Proceedings of the ACM on Programming Languages 5 (ICFP), 2021. Formalisation of statutes as executable code with structure mirroring the legal text. John Backes and colleagues, "Semantic-Based Automated Reasoning for AWS Access Policies Using SMT", Formal Methods in Computer-Aided Design, 2018. The Zelkova system, an example of SMT reasoning deployed at very large scale. Amazon Web Services, documentation for Automated Reasoning checks in Amazon Bedrock Guardrails, 2025. A commercial implementation of solver-based verification of language-model outputs against formalised policies; useful as a concrete reference design, read with the cautions in Chapter 9. Hashtags: #NeuroSymbolicIntegration #NeuroSymbolicAI #NeuralSymbolicAI #DeepLearning #FormalLogic #ArtificialIntelligence #MachineLearning #SymbolicAI #NeuralNetworks #HybridAI #LogicalReasoning #AutomatedReasoning #KnowledgeRepresentation #KnowledgeGraphs #Ontologies #FormalVerification #ExplainableAI #XAI #TrustworthyAI #ReliableAI #ResponsibleAI #AISafety #AIHallucinations #HallucinationDetection #AIValidation #NeuralReasoning #SymbolicReasoning #DeductiveReasoning #FirstOrderLogic #PropositionalLogic #DescriptionLogic #LogicProgramming #Datalog #SATSolving #SMTSolving #ConstraintSolving #AnswerSetProgramming #ProbabilisticLogic #DifferentiableLogic #LogicTensorNetworks #DeepProbLog #SemanticLoss #TheoremProving #AutomatedTheoremProving #ProofAssistants #LeanTheoremProver #FormalMethods #NeuralNetworkVerification #RuntimeAssurance #SafetyCriticalAI #ConstrainedGeneration #ConstrainedDecoding #RetrievalAugmentedGeneration #GraphRAG #SemanticWeb #RuleBasedSystems #ExpertSystems #AICompliance #AIAccountability #NeuroSymbolicReasoning #AIResearch

Download the Book (PDF): Introduction Somewhere in the first weeks of university, usually before the first essay is due, someone says it. It might be a roommate joking over a tray of dining-hall pasta, a relative at the farewell dinner, an older sibling offering advice, or a caption under a video that has already been watched a few million times. "Watch out for the freshman fifteen." The phrase arrives as a joke, but it does not land like one. It lands like a warning, and a warning asks for vigilance. From that moment, many students begin to watch themselves in a way they did not quite watch themselves before. This book is about that watching. It is not, at bottom, a book about weight. It is a book about attention: where it goes, what it costs, and how a single catchy phrase can quietly redirect a young adult's attention from the extraordinary business of building a life toward the narrow and exhausting business of monitoring a body. The argument is simple to state and harder to live. The "Freshman 15" is a myth, and the research on it is fairly clear. Most first-year students do not change in the dramatic way the phrase implies, and the changes that do happen look very much like the ordinary changes of early adulthood that occur whether or not someone goes to college. But debunking the number is not enough, because the number was never the real problem. The real problem is the frame. The phrase teaches students that their bodies are a risk to be managed, that change is failure, that food is a test, and that the first year of university is a period of danger rather than growth. That frame is the product of a much larger system of ideas usually called diet culture, and it does its damage whether or not anyone's body changes at all. The remedy this book offers is not a better diet, and it is not an instruction to love your body every day. It is something more modest and, for most people, more achievable: body neutrality. Body neutrality means treating your body as the vehicle of your life rather than the project of your life. It means eating regularly, adequately and flexibly so that food stops occupying the centre of your mind. It means noticing what your body does rather than auditing what it looks like. And it means having a clear sense of when ordinary worry has become something more serious, and knowing exactly where to turn when it has. Why the first year matters The move to university is one of the few times in life when almost everything changes at once. Students leave a household where meals may have appeared on a schedule someone else set. They gain complete control over what, when and whether they eat, often for the first time, usually alongside new freedoms around sleep, alcohol, money and time. They are surrounded by hundreds or thousands of peers of roughly the same age, which makes comparison constant and easy. They are forming an adult identity in public, and much of that public now lives on a phone. These are exactly the conditions under which body worries tend to intensify. They are also, not coincidentally, the conditions under which eating disorders commonly emerge. Research on college populations has repeatedly found that eating disorder symptoms are common among students and that most students with those symptoms do not receive treatment. A study of students at a large American university, published in the Journal of American College Health in 2011 by Daniel Eisenberg and colleagues, found that a substantial minority of undergraduate women and a smaller but meaningful share of undergraduate men screened positive for eating disorder symptoms, that the symptoms tended to persist over two years, and that only a small fraction of those who screened positive had received any mental health treatment in the previous year. The lesson is not that every student is at risk of an eating disorder. It is that the first years of university are a genuinely consequential moment, and that the ideas students absorb about food and bodies during this period can shape the next decade. That is why a throwaway phrase deserves a whole book. The phrase is small; the habits of attention it encourages are not. What this book is and is not This book is written for students, and for the people who care about them: parents, resident assistants, coaches, advisers and friends. It draws on research in psychology, public health and nutrition, and it tries to be honest about what that research does and does not show. Where evidence is strong, it says so. Where evidence is mixed or still developing, it says that too. A few commitments shape the whole book, and it is worth stating them plainly. It contains no calorie figures, no target weights, no body-size numbers and no "ideal" measurements of any kind. That is deliberate. Numbers of this kind are among the most common hooks by which diet culture draws people in, and for readers who are struggling with food, they can do real harm. When the book discusses research on weight change, it describes what the findings mean rather than reproducing figures that could be turned into goals. It does not describe disordered eating behaviours in instructive detail. It names warning signs clearly, because naming them helps people recognise trouble in themselves and in others, but it does not provide the kind of detail that could function as a manual. It is not neutral about diet culture. It takes the position, supported by a substantial body of research, that intentional dieting for weight loss rarely achieves what it promises and often creates the very preoccupation it claims to solve. It also takes seriously that bodies and health are complex, that some students have medical conditions requiring specific dietary guidance, and that the goal is not to replace one set of rigid rules with another. This book is educational. It is not a substitute for individual medical, nutritional or psychological advice. If you have a health condition that affects how you eat, if you are worried about your eating, or if anything in these pages resonates uncomfortably, the right next step is a conversation with a clinician: a doctor, a counsellor, or a registered dietitian, ideally one experienced with eating concerns. Many campuses provide these services at little or no cost to enrolled students. Chapter 8 explains how to find them and what to expect. Some parts of the book refer to American institutions and resources, such as specific helplines, because that is where the "Freshman 15" phrase originated and where it remains most entrenched. The same pressures exist in many other countries, but support services, health systems and campus structures vary widely by country and by institution. Wherever American specifics appear, readers elsewhere should look for the local equivalent. How the book is organised The chapters follow the logic of the argument. Chapter 1 examines the myth itself: where the phrase came from, what the research actually found, and why a claim with so little evidence behind it has proven so durable. Chapter 2 turns to the body, describing the ordinary ways bodies change in late adolescence and early adulthood and why treating that change as an emergency causes more harm than the change itself. Chapters 3 and 4 look at the environment students live in. Chapter 3 maps how diet culture shows up on a modern campus, often dressed as wellness, and examines what the research says about dieting. Chapter 4 addresses the attention economy of bodies online, where comparison is built into the architecture of the platforms students use every day. Chapters 5 and 6 are about practice. Chapter 5 sets out what body neutrality is, how it differs from body positivity, and how to build it through small, repeatable habits. Chapter 6 applies the same thinking to food: how to eat regularly and flexibly in the specific conditions of campus life, including dining halls, tight budgets, late nights and busy weeks. Chapter 7 recognises that body image pressures are not the same for everyone. Men, athletes, LGBTQ+ students, students from different cultural backgrounds, students in larger bodies and students facing food insecurity each encounter distinct versions of these pressures. Chapter 8 addresses the point at which body worry becomes an eating disorder, with warning signs, guidance for supporting a friend, and a clear account of where help is available. The conclusion does not summarise. It asks what follows from all of this, for individual students and for the institutions that shape their environment, and what questions remain genuinely open. A note on how to read If you are reading this because you are worried about yourself, you do not need to read in order. Chapter 8 can be read first. If you are reading because a phrase like "freshman fifteen" has been rattling around your head since orientation, start at the beginning; the argument builds. And if, as you read, you notice yourself using the book to check whether you are doing things right, pause. That impulse, the urge to turn every piece of information into a rule and every rule into a test, is exactly the habit this book hopes to loosen. The aim is not to give you a new standard to meet. It is to give you back some of the attention the old standards took. Chapter 1: The Making of a Myth Most myths are old. This one can be dated. The earliest documented use of the phrase "Freshman 15" appeared on the cover of Seventeen magazine in August 1989, in the line "Fighting the Freshman 15." Within a decade the phrase had spread through newspapers, television, campus health pamphlets and orientation talks. By the time today's students were born, it had become something people simply knew, the way people know that summer follows spring. It is worth pausing on that origin. The phrase did not emerge from a research finding that was later popularised. It emerged from a magazine aimed at teenage girls, framed from its first appearance as a fight. The number was chosen, as far as anyone can tell, because it was alliterative and memorable. "Freshman fifteen" has a rhythm that "freshman three" or "freshman variable" does not. The claim came first; the investigation came later. And when the investigation came, it did not find what the phrase promised. What the research actually found Once the phrase was in circulation, researchers did what researchers do: they measured. Over the following decades, dozens of studies followed first-year students across an academic year, recording how their weight changed. The picture that emerged is consistent enough to state with some confidence, although it comes with nuances worth understanding. The largest and most frequently cited American study was published in 2011 by the economists Jay Zagorsky and Patricia Smith in Social Science Quarterly, under the pointed title "The Freshman 15: A Critical Time for Obesity Intervention or Media Myth?" They used data from the National Longitudinal Survey of Youth 1997, a large, nationally representative survey that followed thousands of young Americans over many years. Because the survey tracked young people whether or not they went to college, the researchers could do something most campus-based studies could not: compare students with their same-age peers who were not in college. Their findings were striking. The average change during the first year was a small fraction of the famous fifteen. No more than about one in ten first-year students experienced a change anywhere near the headline figure, and roughly a quarter of students actually lost weight. Most importantly, the difference between students and non-students of the same age was very small. Young people of that age tended to change somewhat over time whether they were in a dormitory or not. Zagorsky summarised the conclusion bluntly in the university's press release: the "freshman 15" was a media myth, and it was not college that led to weight gain but becoming a young adult. A second major contribution came from a team at the University of Oxford. In 2015, Claudia Vadeboncoeur, Nick Townsend and Charlie Foster published a meta-analysis in BMC Obesity that pooled longitudinal studies of first-year university students from 1980 to 2014. They included thirty-two studies, most from North America, and pooled the data from the twenty-two that reported enough detail to combine. The average change they found was, again, a small fraction of fifteen. They also found that a majority of students, around three in five, gained some weight during the first year, while the rest stayed about the same or lost weight. The same team followed students at twenty-three universities in England through an academic year and published the results in 2016. There, too, the average change was modest, and about a quarter of students lost weight. The authors pointed out that around three quarters of students experienced some meaningful change in one direction or the other. It is important to be honest about how these researchers framed their results. The Oxford team, writing from a public health perspective focused on obesity prevention, concluded that first-year weight change was a real phenomenon deserving attention, even if the famous number was wrong. Zagorsky and Smith, by contrast, emphasised that the change was mostly about age rather than college. Both readings are drawn from similar data. What neither supports is the specific claim the phrase makes: that the first year of university reliably produces a large, sudden, alarming change in most students' bodies. Table 1 sets the popular claim beside what the research shows. Table 1. The "Freshman 15" claim compared with research findings. What the phrase implies What research has found Main sources Most first-year students change dramatically Average change is a small fraction of the headline figure Zagorsky and Smith (2011); Vadeboncoeur et al. (2015) Change goes in one direction A substantial minority, often around a quarter, lose weight Zagorsky and Smith (2011); Vadeboncoeur et al. (2016) College itself causes the change Same-age peers not in college change by a similar amount Zagorsky and Smith (2011) The change is a crisis requiring vigilance Change is common and varied in early adulthood All of the above Why a weak claim survived If the evidence against the phrase has been available for well over a decade, why does it persist? Why do students still hear it at orientation, still see it in memes, still worry about it during their first term? The answer says something important about how diet culture works, and it is the first step toward understanding why simply correcting the number does not solve the problem. The first reason is that the phrase is useful to people selling things. A fear that arrives with a specific, predictable timeline is a marketing gift. For decades, magazines, diet programmes, supplement companies and fitness brands have offered solutions to the freshman fifteen: meal plans, workout guides, "dorm-friendly" diets, lists of foods to avoid. A myth that returns every autumn with a new cohort of anxious eighteen-year-olds is a renewable market. The second reason is that the phrase contains a grain of something recognisable. Students' bodies do change in early adulthood, as Chapter 2 explains. Eating patterns genuinely shift when someone moves away from home. A student who notices that their clothes fit differently in November can easily feel that the phrase was confirmed, even if the change is modest, normal and would have happened anyway. The myth survives not because it is accurate but because it offers a ready-made story into which ordinary experience can be slotted. The third reason is that the phrase is socially useful as a joke. It gives students a way to talk about food and bodies with each other in a light register, to bond over shared anxieties, to express a worry without seeming to take it too seriously. Researchers who study "fat talk", the ritual exchange of negative comments about one's own body, have found that this kind of talk is common among young women in particular and that it tends to worsen body dissatisfaction in both speaker and listener. The freshman fifteen is a prepackaged script for exactly this kind of conversation. Someone mentions the pizza they ate at midnight, someone else says "freshman fifteen", everyone laughs, and everyone leaves slightly more self-conscious than before. The fourth and deepest reason is that the phrase fits a larger belief system that most people absorb long before university. That system, usually called diet culture, holds that thinness is a moral and aesthetic achievement, that weight gain is a personal failure, that food must be controlled, and that bodies are projects requiring constant correction. Within that system, the freshman fifteen does not need evidence. It simply confirms what the system already believes: that freedom around food is dangerous, and that young people, left to themselves, will lose control. The harm is in the frame, not the number Here is the central point of this chapter, and in some ways of the whole book. Even if the research had found that most students did change dramatically in their first year, the phrase would still be doing harm. Its damage does not depend on its accuracy. It depends on what it asks students to do. The phrase asks students to watch. It encourages them to treat the first year of university as a period of bodily danger requiring surveillance: checking mirrors, checking clothes, checking scales, checking plates. It suggests that food in a dining hall is a hazard rather than nourishment. It implies that the reasonable response to new freedom is new restriction. And it plants the idea that any change in the body during this period is evidence of failure. Consider a first-year student who arrives on campus having never thought much about food. She ate what her family cooked, played a sport in high school, and did not own a scale. In her first week, she hears the phrase three times: once from an aunt, once from a hallmate, once in a video. None of these people means harm. But she begins, almost without deciding to, to notice what she eats. She skips dessert at the dining hall, not because she does not want it but because of the phrase. She starts looking at her reflection in the bathroom mirror more carefully. By the end of the term, she is thinking about food far more than she ever did at home, and the thinking feels urgent. Her body may not have changed at all. Her attention has. This composite example is not unusual, and it illustrates why the most common "solution" to the freshman fifteen, eating carefully to avoid it, is part of the problem. Advice to "stay mindful of the freshman fifteen" or to "make smart choices in the dining hall" may be well intended, but it reinforces the frame. It still treats the body as a risk and food as a test. The student who follows it has not escaped the myth; she has been recruited into it. There is also a straightforward psychological mechanism at work. Attention shapes experience. When people are told to watch for something, they notice it more, interpret ambiguous evidence as confirmation, and feel more distress when they find it. A student primed to worry about body change will read normal fluctuations, such as feeling bloated after a large meal or noticing that jeans feel tight after a salty dinner, as evidence of the thing they feared. The phrase does not just describe an anxiety. It manufactures one. A family of phrases The freshman fifteen is not alone. It belongs to a family of phrases that attach a feared bodily change to a life transition: the "summer body" that must be earned by June, the "holiday weight" that must be undone in January, the "quarantine fifteen" that circulated in 2020 when much of the world was confined indoors, the pressure to "get back" a body after pregnancy, the "wedding shred". Each of these phrases does the same work. It takes a period of life that is meaningful for reasons that have nothing to do with appearance, whether a new school, a holiday, a public health emergency or a birth, and it recasts that period as a threat to the body's shape. Seeing the family resemblance is useful, because it shows that the freshman fifteen is not really a claim about university. It is a template. Diet culture has a habit of converting any change in circumstances into a reason for bodily vigilance. Once a student recognises the template, it becomes easier to spot it elsewhere and to decline it. It is also worth noticing who the phrase was originally aimed at. It appeared in a magazine for teenage girls, and for most of its history it has been addressed primarily to young women. That does not mean young men are untouched by body pressures; Chapter 7 discusses how those pressures often take a different form, centred on muscularity rather than thinness. But the phrase's history is a reminder that body anxiety is not distributed randomly. It is directed, and it is often directed at people at precisely the moment they are gaining independence. What the first year really changes If the first year does not reliably transform students' bodies, what does it change? Quite a lot, as it happens, and most of it deserves more attention than weight. It changes routines. A student who ate breakfast at the same time every school day for twelve years may suddenly have a first class at eleven on Tuesdays and at eight on Wednesdays. Meals become irregular not because of any failure of discipline but because the structure that used to organise them has gone. It changes sleep. Late-night conversations, shared rooms, noise in residence halls and the absence of anyone enforcing a bedtime mean that many first-year students sleep less and less regularly than they did at home. Sleep affects mood, concentration, appetite and the capacity to cope with stress, and it is one of the most underrated factors in how students feel about themselves. It changes stress. Academic demands rise, social worlds have to be built from scratch, and money often becomes a live concern for the first time. Stress affects appetite in different ways for different people; some eat less, some eat more, some eat erratically. It changes the social meaning of food. At home, food may have been a family matter. At university, it becomes a social currency: shared pizza during study sessions, late-night runs to a diner, dinners that double as the main opportunity to see friends. Food becomes woven into belonging. And for many students it introduces alcohol in a new way, with its own effects on sleep, appetite and judgement. Each of these changes matters for wellbeing. A student who is not sleeping, not eating regularly, overwhelmed by stress and struggling to find friends will feel unwell regardless of what their body looks like. The freshman fifteen directs attention to the one variable that matters least and away from the ones that matter most. Part of dismantling the myth is simply redirecting that attention to the things that genuinely shape how the first year goes. Correcting the record is necessary but not sufficient It would be satisfying to end this chapter by declaring the myth busted and moving on. Many articles on the freshman fifteen do exactly that: they cite the research, reassure readers that the number is exaggerated, and then, almost without exception, pivot to a list of tips for "avoiding weight gain in college". This is the characteristic move of diet culture in its modern form. It concedes the specific claim while preserving the underlying premise. The message becomes: the fifteen is a myth, but you should still be careful. This book takes a different position. The research on the freshman fifteen is useful because it removes a specific fear, and removing that fear matters. But the more important lesson is that the fear was never really about fifteen of anything. It was about the idea that a changing body in early adulthood is a problem to be solved. That idea is the one worth dismantling. Doing so does not mean that health does not matter, or that students should ignore their bodies. It means shifting the question. Instead of asking "How do I prevent my body from changing?", a student can ask better questions. Am I eating enough, regularly enough, to have energy for my classes and my life? Am I sleeping? Am I moving in ways I enjoy? Am I connected to people? Is food taking up more of my mental space than it should? These questions are about health and wellbeing in the full sense. None of them requires a scale, and none of them is answered by the freshman fifteen. The next chapter looks at what actually happens to bodies during the years students spend at university, and why the ordinary facts of physical development in early adulthood deserve to be understood rather than feared. A short practice for this week Before moving on, it helps to notice how the phrase operates in your own environment. For one week, pay attention to every time you hear or see the freshman fifteen, or any variation of it: in conversation, online, in advertising, in your own thoughts. Do not argue with it. Simply notice who says it, in what tone, and how you feel immediately afterward. Many students who try this are surprised by how often the phrase appears and by how reliably it produces a small flicker of self-consciousness. That flicker is the thing to understand. It is not a reaction to your body. It is a reaction to a sentence. And sentences, unlike bodies, can be set aside. Chapter 2: Bodies in Transition There is a quiet assumption buried inside the freshman fifteen, and it is worth dragging into the light. The assumption is that the body a student brings to university at eighteen is the correct body, the finished version, and that any departure from it is a deviation to be corrected. Almost nothing in human biology supports that assumption. At eighteen, bodies are not finished. They are still in the middle of a long developmental arc that continues well into the twenties, and change during this period is not a sign that something has gone wrong. It is a sign that time is passing in a living organism. This chapter does not describe what a body "should" look like at any age, and it contains no numbers of that kind. Its purpose is narrower: to replace the image of the frozen eighteen-year-old body with a more accurate picture of the body as something that develops, fluctuates and varies, and to show why treating that change as an emergency tends to cause more trouble than the change itself. Development does not stop at eighteen Most people know that adolescence is a period of rapid physical change. Fewer people realise that development continues, more slowly, through the late teens and twenties. Consider the skeleton. Bones continue to accumulate mineral density through the late teens and into the twenties, with most people reaching their peak bone mass somewhere in early adulthood. The bone a person builds during these years is, in effect, the savings account they draw on for the rest of their life. Adequate nutrition, including enough overall energy, protein and calcium, together with regular weight-bearing activity, supports this process. Chronic under-eating during these years can undermine it, and some of that loss may not be fully recoverable later. This is one of the clearest examples of why restricting food during university is not a neutral act. It happens during a window when the body is still building structures it will depend on for decades. Consider the brain. Research in developmental neuroscience has shown that the brain continues to mature into the mid-twenties, particularly in regions associated with planning, impulse control and weighing long-term consequences. The brain is an energy-hungry organ, and it does not function well when it is underfed. Students who restrict their eating often report difficulty concentrating, irritability and preoccupation with food, which are exactly the effects one would expect when a developing brain is asked to work on too little fuel. Consider body composition and shape. During the late teens and early twenties, many people's bodies continue to change in ways that have nothing to do with lifestyle. Shoulders may broaden, hips may widen, muscle may increase, fat distribution may shift as hormonal patterns settle into their adult form. Someone whose body was relatively straight up and down at sixteen may find it has a different shape at twenty-one. None of this is a failure. It is the body completing a process that began at puberty. Taken together, these facts change the meaning of the question students are taught to ask. The freshman fifteen invites a student to compare their body in November to their body in August and to interpret any difference as a warning. But a body that is still developing will look and feel different over time. A student who reaches the end of university with exactly the body they had at the start would be the anomaly. There is a further reason the comparison with the eighteen-year-old body is misleading. The body a student had in their final year of school was often shaped by circumstances that no longer exist. A student who played a sport five afternoons a week, walked to school, ate meals cooked at home on a fixed schedule and went to bed at a set time had a particular routine, and their body reflected it. When the routine changes, as it inevitably does at university, the body may change with it. That is not evidence that the student has lost control. It is evidence that the body responds to the life it is living, which is exactly what a healthy body is supposed to do. Treating the last year of school as a baseline to be defended turns one particular, temporary set of circumstances into a permanent standard. Bodies fluctuate, and that is not information Beyond long-term development, bodies change from day to day and week to week in ways that have nothing to do with any lasting change in tissue. The amount of water the body holds varies considerably depending on salt intake, hydration, hormones, temperature, exercise and recent meals. Someone who eats a salty dinner, flies on a plane, or has a hard training session may carry noticeably more water the next day. The menstrual cycle produces regular shifts in fluid retention, bloating and how the body feels, and many people who menstruate notice predictable changes in how their clothes fit across the month. The contents of the digestive tract vary from hour to hour. Muscles that have been worked hard hold extra fluid as they repair. These fluctuations mean that a single observation of the body, whether in a mirror, in the fit of a pair of jeans, or on a scale, tells a person very little about anything meaningful. Yet diet culture teaches people to treat exactly these snapshots as verdicts. A student who wakes up feeling bloated after a weekend of irregular meals and poor sleep may conclude that the freshman fifteen has arrived, when what has actually arrived is Monday. This matters because the interpretation drives behaviour. If a student reads normal fluctuation as a sign of failure, the natural response is to compensate: skip breakfast, cut something out, exercise harder. Those responses tend to produce more fluctuation, more irregular eating and more preoccupation, which then produce more readings that look like failure. The cycle is driven not by any real change in the body but by a misreading of noise as signal. Research on frequent self-weighing among young adults has produced mixed findings; some studies report no harm for some groups, while others find associations with greater body dissatisfaction and disordered eating, particularly among young women and people already prone to body concerns. What is not in dispute is that for many people, especially during a stressful transition, frequent checking of the body, whether by scale, mirror, pinching, measuring or trying on particular clothes, amplifies worry rather than resolving it. Clinicians who treat eating disorders often describe this behaviour as "body checking" and regard reducing it as an important part of recovery. For students who notice they are checking often and feeling worse afterward, the most useful experiment is usually to check less. Bodies vary, and most of the variation is not chosen A third fact complicates the freshman fifteen further. Human bodies vary enormously in size and shape, and most of that variation is not a matter of individual choice. Twin and family studies have consistently found that genetics account for a substantial share of the differences in body size between people. Two students who eat similarly, move similarly and sleep similarly may have quite different bodies, and may respond quite differently to the same changes in routine. This does not mean that behaviour has no influence on bodies; it clearly does. It means that the influence operates within ranges that differ from person to person, and that the popular idea that anyone can achieve any body through enough discipline is false. Diet culture relies heavily on the opposite belief. If body size were fully under individual control, then larger bodies would be evidence of personal failure and smaller bodies evidence of virtue. That moral reading is what gives weight stigma its force, as Chapter 7 discusses. Recognising how much body size is shaped by factors outside an individual's control does not remove every question about health, but it does remove the moral charge. A student whose body is larger than a friend's is not less disciplined, less intelligent or less worthy. They are differently built. There is also a growing recognition among researchers and clinicians that attempting to override the body's own regulation through sustained restriction tends to provoke powerful counter-responses: increased hunger, preoccupation with food, reduced energy and, often, eventual regain. The physiological details of how the body regulates its size are still being studied and debated, and it would be an overstatement to claim that science has settled the matter. But the practical pattern, that intentional weight loss through dieting is difficult to sustain for most people, is well documented, and Chapter 3 returns to it. The cost of treating change as an emergency If change is normal, fluctuation is noise and variation is largely unchosen, what is the harm in keeping an eye on things anyway? Surely a bit of vigilance is harmless. For some people, perhaps it is. But for many students, especially in the first year, vigilance has real costs, and they are worth listing. It costs attention. Every minute spent monitoring the body is a minute not spent on the things university is for: learning, friendship, exploration, rest. Students who are preoccupied with food and body often describe a kind of background hum that never quite switches off, a constant low-level calculation that follows them into lectures, conversations and sleep. It costs pleasure. Food is one of the most reliable sources of pleasure and connection in human life. Students who approach every meal as a test lose access to that pleasure, and often to the social occasions that revolve around food. It costs energy. A student who eats less than they need, whether through deliberate restriction or simply through anxious, irregular eating, will have less energy for everything else. Fatigue, poor concentration and low mood are common consequences. It costs flexibility. Rigid rules about food make it harder to participate in ordinary university life: spontaneous dinners, late-night study sessions, trips with friends, cultural celebrations. The student with the rules often ends up either avoiding these occasions or attending them with anxiety. And for some students, it costs much more. Body monitoring and dietary restriction are among the most common pathways into eating disorders, which are serious illnesses with significant physical and psychological consequences. Not everyone who worries about their body will develop an eating disorder. But almost everyone who develops one began by worrying about their body. Consider a second-year student who, after hearing that the first year is when "everyone gets out of shape", begins weighing himself every morning in his first term. Some mornings the number is lower and he feels relieved; some mornings it is higher and he feels a spike of anxiety that shapes his whole day. On higher days he skips lunch and spends an extra hour at the gym. By spring he has noticed that he thinks about food almost constantly, that he dreads meals with friends, and that his grades have slipped. His body has barely changed across the year. The vigilance itself has become the problem. When change is worth a conversation None of this means that bodily change is always meaningless. Sometimes a change in the body is a message worth listening to, and a body-neutral approach does not ask anyone to ignore those messages. It asks them to read the right ones. Rapid, unexplained change in either direction, particularly when it comes with other symptoms, is worth raising with a clinician. Persistent fatigue that sleep does not fix, unusual thirst, feeling cold much of the time, dizziness, hair thinning, changes in bowel habits, or periods that become irregular or stop can all point to something that deserves attention, from thyroid conditions to anaemia to the effects of not eating enough. Some commonly prescribed medications, including certain antidepressants, mood stabilisers and hormonal treatments, can affect appetite and body size, and students who start a new medication and notice changes should talk to the prescriber rather than trying to counteract the effect through restriction or stopping the medication on their own. Sudden changes in appetite can also accompany depression, anxiety and grief, all of which are common at university and all of which respond to support. The point is that the useful signals are about function: energy, sleep, mood, digestion, menstrual health, the ability to concentrate and recover. Size on its own is rarely the most informative signal, and focusing on it can obscure the others. A student who has lost weight during a hard term and is being complimented for it may in fact be depressed, under-eating or unwell. A student who has gained weight may be perfectly healthy and simply developing. Appearance is a poor proxy for either. Students who find medical appointments stressful because of weighing are entitled to ask questions. In many clinics it is possible to ask whether a weight measurement is necessary for the visit, to ask to be weighed facing away from the display, or to ask that the number not be read aloud. Clinicians who work with eating concerns often recommend this approach for patients who find the number distressing. There are situations where weight is medically necessary, for example for certain medication doses or when monitoring particular conditions, and in those cases a clinician can explain why. But the request itself is reasonable, and a good clinician will take it seriously. A different relationship with change What would it look like to relate to bodily change without alarm? A few principles help. The first is to expect change. A student who begins university knowing that their body will likely look and feel somewhat different at twenty-two than at eighteen, and that this is the ordinary course of development, is far less vulnerable to the panic the freshman fifteen invites. Expecting change does not mean welcoming every change enthusiastically. It means not treating change as evidence of failure. The second is to judge the body by how it works rather than how it looks. Is there enough energy to get through the day? Is sleep reasonable? Can the student concentrate in class, enjoy movement, recover from a cold? These are the signs of a body that is being looked after. They are also far more informative than a reflection. The third is practical and underrated: dress the body you have. Many students keep clothes that fit a previous version of themselves, and trying them on becomes a regular ritual of self-judgement. Clothes that are uncomfortable are a daily reminder that the body is "wrong". Replacing them, where budget allows, with clothes that fit now, even a few basics from a second-hand shop, removes a surprisingly large source of distress. The goal is not to celebrate the body but simply to stop being reminded, several times a day, that it has supposedly failed. The fourth is to reduce checking deliberately. If a student notices that they weigh themselves often, examine themselves in mirrors repeatedly, or compare their body with others' in specific ways, it can help to set a simple experiment: check less for two weeks and observe what happens to mood and preoccupation. Many people find that the anxiety rises briefly and then settles to a lower level than before. For students whose checking feels compulsive or impossible to reduce, that is useful information too, and worth discussing with a counsellor. The fifth is to remember that the body has a history and a future. The body a student has at university is the same body that carried them through childhood, that will carry them through the rest of their life, that will grow older and change again many times. It is not a project to be completed by graduation. It is the ongoing physical basis of a life. Seen from that longer perspective, the question of whether it changed a little in the first year of university looks very small indeed. The next chapter turns from the body to the environment around it, and to the many ways in which a modern campus quietly teaches students to distrust both their bodies and their food. Chapter 3: Diet Culture on Campus Very few students arrive at university thinking of themselves as dieters. Many of them would say, sincerely, that they do not believe in diets, that they know diets do not work, that they just want to be healthy. And yet within a few weeks, many of those same students are skipping meals before a party, dividing dining-hall food into "good" and "bad", tracking what they eat on an app "just to see", and feeling guilty after dessert. They have not decided to diet. They have simply absorbed the ambient rules of the place. Those rules have a name. The phrase "diet culture" is used by dietitians, psychologists and writers to describe a set of beliefs so widely held that they often go unnoticed. In her book Anti-Diet, the dietitian Christy Harrison describes diet culture as a system of beliefs that equates thinness with health and moral virtue, promotes weight loss as a means of attaining higher status, demonises certain foods and ways of eating while elevating others, and oppresses people whose bodies do not match its ideals. One does not have to accept every part of that definition to recognise its core. Diet culture is the belief that bodies should be smaller, that food should be controlled, and that the effort to achieve both is a sign of good character. This chapter looks at how that belief system appears on a modern campus, often without using the word "diet" at all, and at what the research says about the outcome it promises. Diet culture rarely calls itself a diet The first thing to understand about diet culture today is that it has learned to disguise itself. Old-fashioned diets announced themselves: a named plan, a set of rules, a promised result. Many students now recognise those and roll their eyes. But the same rules now travel under other names. They travel as wellness. A campus "wellness challenge" that awards points for skipping sugar, or a residence hall programme on "healthy eating" that consists mainly of lists of foods to avoid, carries diet culture's core message while presenting itself as self-care. They travel as clean eating. The language of "clean", "whole", "real" and "processed" food sounds like nutrition, and some of the underlying advice, such as eating a variety of plant foods, is reasonable. But when foods are sorted into morally loaded categories, "clean" and "dirty", "good" and "bad", "healthy" and "junk", eating becomes a moral performance. Clinicians have described a pattern, sometimes called orthorexia, in which preoccupation with eating "correctly" becomes rigid, anxious and eventually harmful. Orthorexia is not a formal diagnosis in the major diagnostic manuals, and researchers continue to debate how best to define it, but the pattern it describes is familiar to anyone who works with students. They travel as fitness. Gym culture, especially online, often frames exercise as a way to "earn" food or "burn off" meals already eaten. When movement becomes a form of payment for eating, both movement and eating lose their ordinary meanings. They travel as data. Food-tracking apps, fitness trackers and wearable devices turn eating and movement into numbers, and numbers invite targets. Some people use these tools without difficulty. For others, particularly people already prone to worry about their bodies, tracking quickly becomes compulsive, and the numbers begin to feel more authoritative than hunger, fullness, pleasure or energy. They travel as jokes. The freshman fifteen is the most famous, but there are many others: comments about needing to "be good" this week, about a meal being "sinful", about having "earned" a treat, about "starting again on Monday". These remarks are so common that they can seem like background noise. But research on "fat talk", a term popularised by the anthropologist Mimi Nichter in her 2000 book of the same name, has found that ritual negative body talk is widespread among young women and is associated with greater body dissatisfaction. It functions as a social script, a way of bonding through shared self-criticism, and it teaches everyone in the conversation that disliking one's body is normal and expected. And they travel as care. Parents, coaches, friends and even health professionals sometimes pass on diet culture out of genuine concern. A parent who warns their child about the freshman fifteen, a coach who comments on an athlete's body, a friend who suggests a "detox" after a holiday, may all be trying to help. Recognising diet culture does not require assuming bad intent. It requires noticing the message beneath the concern. Table 2 sets out some of the most common campus versions of these messages, what they assume, and a more neutral alternative. Table 2. Common campus diet-culture messages and neutral alternatives. What you might hear What it assumes A more neutral alternative "Watch out for the freshman fifteen." Body change in the first year is a danger "Your routines will change; look after your sleep and meals." "I was so bad today, I had dessert." Some foods are moral failings "I had dessert." "I need to earn that pizza at the gym." Food must be paid for with exercise "I'm hungry, and I also like going to the gym." "I'll skip dinner since we're going out." Food should be cut to compensate for other choices "I'll eat dinner so I feel steady tonight." "Let's do a sugar-free challenge." Restriction equals health "Let's cook a meal together this week." "You look great, have you lost weight?" Smaller bodies deserve praise "It's good to see you. How have you been?" Where diet culture lives on campus Beyond these messages, diet culture is built into some of the physical and social structures of university life. In the dining hall, it may appear in labelling. Some institutions display detailed nutrition information next to every dish, or use colour-coded systems to mark foods as more or less healthy. Information about ingredients and allergens is genuinely important, and students with medical dietary needs rely on it. But for students prone to counting or restriction, prominent numerical labelling on every item can make each choice feel like an exam. Students who find this difficult can often choose a small number of meals they like and rely on those, without reading every label, while still checking allergens where needed. In the gym, it may appear in the messaging on the walls, the "transformation" challenges promoted by trainers, and the unspoken norms of who belongs where. Some campus recreation centres have moved toward weight-neutral messaging, removing scales from open areas and emphasising strength, fun and stress relief rather than appearance. Others have not. In social life, it may appear around specific events. Formals, spring break trips, athletic seasons and holiday visits home are all moments when students report heightened pressure to change their bodies, sometimes explicitly encouraged by peers. Groups that bond over shared restriction, such as a team or a house that collectively "cuts" before an event, create a powerful social pressure that is very hard for an individual to resist. In health messaging, it may appear in well-meaning campaigns that focus narrowly on weight. Public health efforts to reduce obesity have sometimes produced materials for young people that emphasise weight control, and researchers who study eating disorder prevention have raised concerns that such messages can inadvertently increase body dissatisfaction and disordered eating. There has been growing interest in approaches that promote health behaviours, such as regular meals, enjoyable movement and adequate sleep, without making weight the target. And in the classroom, it may appear in unexpected ways: a nutrition course that asks students to track their own intake for an assignment, a psychology lecture that uses body-size examples carelessly, a health science module that frames larger bodies exclusively as a problem. Students who find these assignments distressing can usually talk to the instructor or to disability or wellbeing services about alternatives. What dieting actually does The deepest reason to be sceptical of diet culture is that its central promise, that controlled eating will produce a smaller body and that a smaller body will produce happiness, health and status, is not well supported by evidence. The research on intentional weight loss through dieting is extensive, and its broad conclusions have been stable for decades. In 2007, Traci Mann and colleagues at the University of California, Los Angeles, published a review in American Psychologist examining long-term studies of calorie-restricting diets. They concluded that while people often lost weight in the first months of a diet, most regained that weight over the following years, and that a substantial share ended up heavier than when they began. They also noted that the studies they examined probably underestimated regain, because of methodological weaknesses such as reliance on self-report and high dropout rates. Their conclusion was that diets did not lead to sustained weight loss or health benefits for the majority of people. Research on adolescents and young adults points in the same direction and adds a further concern. Project EAT, a large longitudinal study led by Dianne Neumark-Sztainer at the University of Minnesota, followed thousands of adolescents over time. In a 2006 paper in the Journal of the American Dietetic Association, the team reported that adolescents who dieted or used unhealthy weight-control behaviours were, five years later, more likely to have gained weight and more likely to engage in binge eating and more extreme weight-control behaviours than those who did not. In other words, dieting in adolescence predicted not the outcome dieters hoped for, but its opposite, along with a raised risk of disordered eating. Why would this be? Part of the answer lies in how bodies and minds respond to deprivation. One of the most famous studies in the history of nutrition science, the Minnesota Starvation Experiment conducted by Ancel Keys and colleagues during the Second World War and published in 1950 as The Biology of Human Starvation, placed healthy young male volunteers on a severely reduced diet for several months. The men became preoccupied with food to a remarkable degree: they talked about it, dreamed about it, collected recipes and cookbooks, and found it hard to think about anything else. Many became irritable, anxious and depressed. When their food was restored, many found they could not feel satisfied for a long time and ate far more than before. The men in the study had no history of eating problems. The preoccupation was produced by the restriction itself. The Minnesota study was extreme, and ordinary dieting is not the same as semi-starvation. But the direction of the effect has been observed repeatedly in less extreme forms. Psychologists studying "restrained eating", beginning with the work of Peter Herman and Janet Polivy in the 1970s, found that people who habitually try to restrict their eating are more likely to overeat once their rules are broken, a pattern sometimes described informally as the "what-the-hell effect". A student who has set a rigid rule, eats something outside it, and then feels that the day is ruined anyway, is experiencing exactly this pattern. The rule produces the loss of control it was meant to prevent. This is the dieting paradox, and it is the single most important thing to understand about diet culture. Restriction does not reliably lead to control. It more often leads to preoccupation, cycles of restriction and overeating, and a worsening relationship with food. For young adults, it also carries a raised risk of eating disorders. None of this means that nutrition does not matter, or that what people eat has no effect on health. It clearly does. It means that the specific strategy diet culture recommends, deliberately eating less than the body wants in order to become smaller, tends to backfire, and that health is better served by approaches that do not make weight the target. Stepping out without stepping away A student does not need to leave university, delete every app or confront every friend in order to resist diet culture. Some small, practical moves go a long way. The first is to notice and name. When a message about food or bodies appears, whether in a conversation, an advertisement or one's own thoughts, it helps to ask: is this diet culture? Simply labelling it creates a little distance. The thought "I shouldn't have eaten that" becomes "that's the diet-culture voice again", which is much easier to set aside. The second is to decline the script without making a scene. When friends start fat talk, you do not have to deliver a lecture. You can simply not join in, change the subject, or say something mildly neutral: "I don't really think about food that way", or "I thought the pasta was good". Research on fat talk suggests that when one person in a group declines to participate, others often feel relieved. Many people join in because they think it is expected, not because they want to. The third is to be careful with compliments. Comments on weight loss, however kindly meant, reinforce the idea that smaller is better and can be deeply harmful to someone who is struggling with an eating disorder, whose weight loss may be a symptom of illness. Compliments on someone's energy, ideas, kindness, style or achievements carry none of that risk. The fourth is to set boundaries at home. Holiday visits can bring comments from relatives about food and bodies. It is reasonable to say, calmly and in advance if possible, that you would prefer people not comment on your body or your eating. If comments come anyway, a short, neutral reply and a change of subject is often enough: "I'd rather not talk about that. How's work going?" The fifth is to question any group practice built around restriction. If a team, society or friend group is collectively cutting before an event, you are allowed to eat normally. It may help to find one ally who feels the same way. If a coach or leader is encouraging restriction, it is worth knowing that campus athletic departments and counselling services are increasingly aware of the risks, and that concerns can be raised confidentially. It can help to see what declining the script looks like in practice. Imagine four friends eating dinner in a residence hall. One of them looks at her plate and says she has been "so bad" this week and needs to "be good" tomorrow. A second agrees and adds a comment about her own stomach. The familiar next move is for the third person to offer her own criticism, and for the conversation to circle for several minutes around who has eaten what and whose body is worse. Instead, the third friend says, "Honestly, I'm trying not to think about food like that anymore. It was making me miserable." There is a brief pause. Then the fourth friend says, "Same, actually," and asks whether anyone has started the reading for tomorrow's seminar. The conversation moves on. Nobody has been lectured, and nobody has been shamed. A script has simply not been performed, and in its absence the group has found something else to talk about. Moments like this are small, but they accumulate. Body talk is contagious in both directions. When enough people in a social group stop participating in fat talk, the group's norms shift, and newcomers learn a different script. Students in leadership roles, such as resident assistants, team captains and society presidents, have particular influence here, because the norms they model tend to become the norms of the group. None of these steps requires anyone to adopt an ideology. They simply reduce the volume of the messages that teach students to distrust their bodies and their food. The next chapter examines where those messages are loudest of all: on the screens students carry everywhere. Chapter 4: The Attention Economy of Bodies A student lying in bed at midnight, phone in hand, scrolling through short videos, is not simply passing time. She is taking part in one of the most sophisticated systems ever built for capturing and holding human attention. Each video she watches, each one she pauses on for a fraction of a second longer than the others, teaches the system something about her. Within days, the system can predict with unsettling accuracy what will keep her watching. If what keeps her watching is bodies, particularly bodies she compares herself with, the system will learn to show her more of them. Previous generations of students encountered diet culture mainly through magazines, television, advertising and conversation. Those influences were powerful, but they were bounded. A magazine ended. A television programme finished. Today's students carry an endless, personalised stream of images and messages about bodies in their pockets, available at every moment of the day, and increasingly shaped by what they have looked at before. This chapter examines what that environment does to body image, what the research can and cannot tell us, and what students can realistically do about it. Comparison is built into the architecture Human beings have always compared themselves with others. In 1954, the social psychologist Leon Festinger proposed social comparison theory, the idea that people evaluate their own abilities and attributes by comparing them with those of others, particularly when there is no objective standard available. Appearance is one of the domains where comparison comes most naturally, because there is no objective standard for what a body should look like, only a shifting set of cultural ideals. Comparison is not always harmful. Comparing oneself with someone who is similar can provide useful information, and comparing oneself with someone admired can sometimes be motivating. But researchers have consistently found that upward comparisons about appearance, comparing oneself with people perceived as more attractive, tend to leave people feeling worse about their own bodies. Social media intensifies this process in several ways. It increases the sheer number of comparisons available. A student in a small town in the past might have compared herself with a few dozen peers and a handful of celebrities. A student today can compare herself with thousands of people in an afternoon. It also skews the comparisons upward. People tend to post the most flattering images of themselves, often edited or filtered, and platforms tend to promote images that attract attention, which often means bodies that closely match cultural ideals. And it blurs the line between peers and professionals. An influencer with a team of photographers, a lighting set-up and editing software appears in the same feed, in the same format, as a classmate's holiday photo. The brain does not easily distinguish between them. Experimental research supports the concern. In a 2015 study published in Body Image, Jasmine Fardouly and colleagues had young women spend a short period browsing their own Facebook accounts, a fashion magazine website, or an appearance-neutral control website. Those who browsed Facebook reported more negative mood than those in the control condition, and among women with a stronger tendency to compare their appearance with others, browsing Facebook was associated with more desire to change aspects of their appearance. In another 2015 study in the same journal, Marika Tiggemann and Mia Zaccardo showed young women either "fitspiration" images, which feature toned, athletic bodies alongside motivational slogans about exercise and eating, or travel images. The women who viewed fitspiration reported more negative mood and more body dissatisfaction afterward than those who viewed travel images, even though fitspiration presents itself as promoting health. These studies measure short-term effects in laboratory conditions, and it would be a mistake to assume that every hour on social media produces equal harm. Research on the long-term effects of social media use on body image and mental health is still developing, and effects appear to vary considerably depending on what people look at, how they engage with it, and their existing vulnerabilities. But the direction of the evidence is consistent enough to take seriously: appearance-focused content, especially when combined with a tendency to compare, tends to make people feel worse about their bodies. Watching yourself be watched There is a second, subtler mechanism at work, and it helps explain why body image concerns can feel so exhausting. In 1997, the psychologists Barbara Fredrickson and Tomi-Ann Roberts proposed objectification theory, which argues that in cultures that routinely evaluate women's bodies, women learn to take an observer's perspective on themselves. They come to monitor their own appearance habitually, as if watching themselves from the outside. The theory calls this self-objectification, and the constant monitoring that follows is often called body surveillance. While the theory was developed with women's experience in mind, later research has found that people of all genders can experience these processes, particularly those whose bodies are frequently judged. The cost of self-objectification is not only emotional. It is cognitive. In a well-known 1998 study, Fredrickson and colleagues asked students to try on either a swimsuit or a sweater alone in a changing room, and then to complete a maths test. Women wearing swimsuits performed worse on the test than women wearing sweaters. The researchers interpreted this as evidence that attention spent monitoring the body is attention unavailable for other tasks. Social media is, in a sense, a machine for self-objectification. It invites users to present images of their bodies for evaluation, to receive quantified feedback in the form of likes and comments, and to compare their own images constantly with others'. Front-facing cameras and filters make the face and body a continual object of inspection. A student who posts a photo and then checks repeatedly how many people have responded to it is engaged in a form of body surveillance that previous generations could not have imagined. The freshman fifteen fits neatly into this environment. It is not only a warning about the body; it is a warning that the body will be seen. The anxiety is partly about how one feels and partly about how one will appear to others, in person and online. Understanding this helps explain why so much of body image distress feels like being watched, and why reducing that feeling often involves reducing the occasions for watching. The content that teaches eating Some of the most influential body-related content online is not explicitly about bodies at all. It is about food. Videos in which people document everything they eat in a day, often accompanied by comments about portion sizes or "staying on track", have become a popular format. So have videos about "healthy swaps", "clean" recipes, fasting routines and supplement regimes. Some of this content is harmless, and some is created by qualified professionals. But much of it is produced by people with no training in nutrition, often with bodies that match cultural ideals, presenting their own eating as a template for others. For a first-year student figuring out how to eat independently for the first time, this content can seem like guidance. The problem is that it presents one person's eating, often filtered, curated and sometimes inaccurate, as a norm. Bodies differ, energy needs differ, and a pattern that suits one person may leave another hungry, tired or preoccupied. A student who models their eating on a stranger's daily video is taking nutritional advice from someone who knows nothing about them. There is also content that is more directly harmful. For many years, online communities have existed that promote eating disorders as a lifestyle, sharing images, tips and encouragement for severe restriction. Major platforms have policies against such content and redirect searches for certain terms to support resources, but enforcement is imperfect, and harmful material often reappears under new hashtags and coded language. Students who find themselves drawn to this content, or who find that their feeds have drifted toward it, should treat that as a meaningful warning sign and consider speaking to someone. Chapter 8 discusses where to turn. The private feed Much of the conversation about social media and body image focuses on public content: influencers, advertising, viral videos. But for many students, some of the most powerful body-related messages arrive through private channels. Group chats circulate screenshots of celebrities' bodies with commentary. Friends share "before and after" posts, diet challenges and workout plans with invitations to join. Photos from a party are posted and tagged within hours, and the question of whether one looks acceptable in them can dominate the next morning. Photographs taken by others deserve particular mention. Many students describe a specific anxiety about being tagged in unflattering pictures, and some avoid social events, or avoid being photographed at them, for this reason. The anxiety is not trivial; it reflects the reality that images now travel quickly and permanently. But avoidance tends to reinforce it. Students who find that fear of photographs is keeping them away from things they would otherwise enjoy may find it useful to talk about the pattern with friends, many of whom feel the same, and to agree on simple norms, such as asking before posting group photos. Editing tools add another layer. Filters and apps that smooth skin, reshape faces and alter bodies are now built into many cameras and platforms, often applied by default. A generation of students has grown up seeing edited versions of their own faces more often than unedited ones, and some report feeling a jolt of disappointment when they catch sight of themselves in an ordinary mirror or an unfiltered photo. Research on the long-term effects of routine self-editing is still limited, but the logic of social comparison suggests an obvious risk: when the comparison is between one's real face and an idealised version of it, the real face will always lose. Turning off default filters, or simply noticing when they are on, is a small way of keeping one's sense of one's own appearance anchored in reality. Consider a second-year student who decides to audit her feeds after a particularly bad week. Over three days, she makes a note each time she closes an app feeling worse than when she opened it. The pattern surprises her. It is not the celebrity accounts that bother her most, but a handful of acquaintances from secondary school who post frequent gym photos, and a group chat in which friends regularly discuss what they are and are not eating. She mutes the acquaintances without unfollowing them. In the group chat, she says, lightly, that the food talk has been getting to her, and two other people immediately agree. The chat does not change overnight, but it changes. The point of the example is not that every problem has a simple solution, but that the most influential parts of a student's media environment are often closer to home, and more changeable, than they appear. Changing the feed and the habit The good news is that the relationship between social media and body image is not fixed. Research suggests that what people see, and how they engage with it, matters a great deal, and both can be changed. Experimental work has found that exposure to different kinds of content produces different effects. In a 2019 study published in New Media & Society, Rachel Cohen, Jasmine Fardouly and colleagues found that young women who viewed body-positive Instagram content, which features a range of body types and messages of acceptance, reported improvements in mood and body satisfaction compared with those who viewed thin-ideal or appearance-neutral content. There is an important caveat: body-positive content still tends to focus on appearance, and some researchers have noted that it can still encourage self-objectification by keeping attention on how bodies look. This is one reason the approach this book recommends, body neutrality, emphasises reducing the overall focus on appearance rather than simply replacing negative images with positive ones. Chapter 5 explores this distinction in detail. Reducing time on social media may also help. A 2023 study by Helen Thai, Gary Goldfield and colleagues, published in Psychology of Popular Media, randomly assigned young people with symptoms of anxiety or depression either to reduce their social media use to about an hour a day for three weeks or to continue as usual. Those who cut back reported improvements in how they felt about their appearance and weight compared with those who did not. The study was relatively small and short, but it is consistent with a broader pattern: less time spent in appearance-focused environments tends to mean less appearance-focused thinking. Drawing on this research and on the practical experience of clinicians, several strategies are worth trying. The first is an audit. Spend a few days paying attention to how particular accounts, creators or types of content make you feel. Not what you think about them, but how you feel immediately after viewing them. Content that reliably leaves you feeling worse about your body, more anxious about food, or more motivated to change your appearance is worth muting or unfollowing, regardless of how popular it is or how "healthy" it claims to be. This includes accounts of friends and acquaintances; muting someone is not the same as rejecting them. The second is to retrain the algorithm deliberately. Recommendation systems respond to what users engage with. Actively seeking out and engaging with content about other interests, such as hobbies, subjects you study, music, humour, nature or causes you care about, gradually shifts what the system offers. Most platforms also allow users to indicate that they are not interested in particular content. Using these tools consistently can change a feed noticeably within a few weeks. The third is to diversify the bodies you see. If your feed is dominated by one body type, deliberately following people with a range of body sizes, ages, abilities and backgrounds, particularly people who are shown doing things rather than posing, helps recalibrate what looks normal. The aim is not to find images to feel good about but to see bodies as ordinary features of human life rather than objects of evaluation. The fourth is to change the settings of use. Many students find that the most harmful scrolling happens at particular times: late at night, when tired, when lonely, or immediately after a stressful event. Keeping phones out of the bedroom, setting app time limits, or simply noticing these vulnerable moments can make a significant difference. Phone-free meals, whether alone or with friends, also help keep eating connected to hunger, taste and company rather than to images. The fifth is to reconsider what you post. Posting photos of one's own body for evaluation, especially photos intended to display weight or shape, reinforces self-objectification and exposes the poster to others' judgement. This does not mean never posting photos of oneself. It means noticing when posting has become a form of seeking reassurance or measuring worth, and experimenting with sharing other things instead. The sixth is to talk about it. Many students assume they are alone in feeling worse after scrolling, when in fact the experience is extremely common. Conversations with friends about what content they find difficult, and agreements to stop sending each other certain kinds of posts, can reduce the pressure for a whole group. None of these strategies requires leaving social media entirely, although some students find that a break helps. They simply recognise that the feed is not a neutral window on the world. It is an environment designed around attention, and students are entitled to shape that environment in ways that protect their own. The next chapter describes what they might do with the attention they reclaim. Chapter 5: Body Neutrality: Doing Rather Than Looking By this point, a reader might reasonably ask: if the freshman fifteen is a myth, diet culture is counterproductive and social media amplifies comparison, what is the alternative? What should a student actually do with their relationship to their own body? The most familiar answer in recent years has been body positivity: the idea that people should love and celebrate their bodies as they are. Body positivity has done valuable work, and for some people it is exactly what they need. But many students find that it does not quite fit. They are told to love their bodies and discover that they cannot, and the failure to feel love becomes one more thing to feel bad about. They look in the mirror, try to feel positive, and feel instead the familiar criticism, now joined by guilt for not being more accepting. This chapter proposes a different, more modest goal. Body neutrality does not ask anyone to love their body. It asks them to stop making their body the centre of their attention. It treats the body as the vehicle through which a person lives, rather than a project to be perfected or an object to be judged, favourably or otherwise. For many people, especially in the pressured environment of university, this is both more honest and more achievable. From positivity to neutrality The body positivity movement has roots in the fat acceptance movement, which emerged in the United States in the late 1960s, when the National Association to Advance Fat Acceptance was founded in 1969 to challenge discrimination against people in larger bodies. Over the following decades, activists, many of them fat women, women of colour and queer people, argued that bodies of all sizes deserved respect and that the stigma attached to larger bodies caused real harm. In the 2010s, the language of body positivity spread widely through social media, where it became associated with images of diverse bodies and messages of self-love. As it spread, body positivity also changed. Critics, including some of the activists who had built the movement, observed that its mainstream version often centred bodies that were only slightly outside conventional ideals, that it was sometimes adopted by brands as a marketing strategy, and that it kept the focus firmly on appearance. The message shifted from "all bodies deserve respect" to "all bodies are beautiful", which, while well intentioned, still implied that beauty was the measure that mattered. Body neutrality emerged partly as a response to these limits. The term gained popularity in the mid-2010s, and it is not a formal clinical construct with a single agreed definition. But its central idea is clear: the body does not need to be loved or admired for a person to live well in it. It needs to be cared for, respected and, much of the time, simply not thought about very much. A student practising body neutrality might not feel beautiful on a given day, but they can still go to class, eat lunch, play a game of football, dance at a party and sleep reasonably well, without their body's appearance dominating their mind. Table 3 compares these orientations. Table 3. Three orientations toward the body. Orientation Core stance Where attention goes Typical inner voice Main limitation Body dissatisfaction The body is a problem to fix Appearance and flaws "I need to change this." Constant criticism and vigilance Body positivity The body should be loved Appearance, reframed as beautiful "I should love how I look." Can feel forced; still centres appearance Body neutrality The body is the vehicle of a life Function, experience and activities "My body got me through today." Less emotionally uplifting; takes practice It is worth being honest that body neutrality has its own limits. It can seem less inspiring than body positivity, and it does not directly address the social injustices that the fat acceptance movement identified; a person can feel neutral about their own body while still facing discrimination because of it. Body neutrality is best understood as a personal practice that sits alongside, rather than replaces, the broader argument that all bodies deserve respect and fair treatment. What the research says about a healthier body image Although "body neutrality" as a term is relatively new, the ideas behind it connect to a substantial body of psychological research on positive body image. In 2015, the psychologists Tracy Tylka and Nichole Wood-Barcalow published an influential review in Body Image setting out what positive body image is and is not. One of their central points was that positive body image is not simply the absence of negative body image. A person can be free of intense dissatisfaction and still lack a healthy relationship with their body. Positive body image, as they described it, includes appreciating the body for its functions and features, accepting aspects of it that do not match cultural ideals, holding a broad view of beauty, and "protective filtering", the ability to take in helpful messages about the body while rejecting harmful ones. They also emphasised that positive body image is not the same as being satisfied with one's appearance at every moment. People with positive body image can have bad body days; what distinguishes them is that those days do not define them. This last point is important for students. A body-neutral approach does not require feeling calm about one's body all the time. It requires being able to have a difficult moment, notice it, and continue with life without letting it take over. Research on body functionality has been particularly relevant to body neutrality. Body functionality refers to everything the body does: its physical capacities, such as walking, dancing or lifting; its internal processes, such as breathing, digesting and healing; its senses; its capacity for creativity and communication; and its role in self-care and connecting with others. In a 2015 study published in Body Image, Jessica Alleva and colleagues in the Netherlands tested a short programme called Expand Your Horizon, in which young women completed a series of writing exercises about the functions of their bodies and why those functions mattered to them. Compared with a control group, the women who completed the programme reported greater body appreciation and body satisfaction and lower self-objectification. Later studies by the same research group and others have found similar effects in different populations. The finding is striking in its simplicity. A few brief exercises focusing attention on what the body does, rather than how it looks, produced measurable improvements. The mechanism appears to be exactly the one this book has emphasised throughout: attention. When attention shifts from appearance to function, the body becomes less an object to be judged and more a partner in living. Self-compassion is another area with growing evidence. The psychologist Kristin Neff, who developed the concept in academic psychology in the early 2000s, describes self-compassion as treating oneself with the same kindness one would offer a friend, recognising that suffering and imperfection are part of shared human experience, and holding painful thoughts in balanced awareness rather than over-identifying with them. In a 2015 study published in Mindfulness, Ellen Albertson, Kristin Neff and Karen Dill-Shackleford found that women who listened to self-compassion meditations over three weeks reported reduced body dissatisfaction and body shame and increased body appreciation compared with a waitlist control group, with benefits maintained at follow-up. Finally, there is strong evidence for a type of group programme that many universities now offer. The Body Project, developed by Eric Stice and colleagues, is a short, peer-led programme in which participants critically examine the thin ideal through discussion, writing and role-play. The theory behind it is cognitive dissonance: when people argue against an ideal out loud, they tend to internalise it less. In a large randomised trial published in the Journal of Consulting and Clinical Psychology in 2008, Stice and colleagues found that the programme reduced thin-ideal internalisation, body dissatisfaction and eating disorder symptoms, and reduced the risk of eating disorder onset over the following three years, compared with a control condition. The Body Project has since been adapted for many settings and is offered at many colleges, sometimes through counselling centres, health promotion offices or student organisations. Students interested in joining or running one can ask their campus counselling or health promotion services. Practising body neutrality Body neutrality is not a belief that can be adopted in an afternoon. It is a set of habits that shift attention gradually over time. The following practices are drawn from the research above and from the experience of clinicians who work with body image. None of them requires feeling good about one's body. They simply change where attention goes. Keep a function list. Once or twice a week, write down a few things your body did that mattered to you. They can be ordinary: carried a heavy bag up the stairs, stayed awake through a long lecture, digested a meal, hugged a friend, recovered from a cold, danced badly at a party, walked across campus in the rain. The point is not to feel grateful on demand but to practise noticing the body as something that does, rather than something that looks. Over weeks, many people find that this practice changes the default way they think about their bodies. Change the questions. When you catch yourself asking "How do I look?", try asking "How do I feel?", "What do I need?" or "What do I want to do today?". These questions redirect attention toward sensation, need and action, which are the domains in which a body is most useful. It is also worth noticing how often appearance-focused questions arise; for many students, simply counting them for a day is revealing. Use neutral language. Harsh self-talk about the body is often automatic. Rather than trying to replace it with praise, which may feel false, experiment with neutral, factual description. Not "my stomach is disgusting" and not "my stomach is beautiful", but "this is my stomach", or "I'm noticing I feel uncomfortable in these jeans today". Neutral description takes the emotional charge out of the observation without requiring a contradicting belief. Treat bad body days as weather. Most people have days when they feel worse about their bodies, often for reasons that have little to do with the body itself: stress, poor sleep, a difficult conversation, a triggering image, an upcoming event. On such days, it helps to recognise the feeling as a passing state rather than a revelation. "I'm having a bad body day" is a more accurate description than "I look terrible". The feeling can be acknowledged, and the day continued. It often passes more quickly when it is not argued with. Engage the body in activities that are not about appearance. Some of the most effective body-neutral experiences involve being absorbed in something physical: a game, a hike, a dance class, climbing, swimming, playing an instrument, cooking. When the body is fully engaged in doing something, attention naturally moves away from how it looks. Students who have lost touch with enjoyable movement can explore campus recreation options, intramural sports, clubs or classes, choosing on the basis of enjoyment rather than calorie burn or appearance goals. Reduce mirror time without avoiding mirrors entirely. Repeatedly checking the body in mirrors tends to increase dissatisfaction, but complete avoidance can also maintain anxiety. A middle path is to use mirrors for practical purposes, such as checking that your collar is straight or your hair is tidy, and then move on. Some clinicians suggest noticing when mirror use has become scrutiny, and gently redirecting attention at that point. Practise self-compassion in difficult moments. When body-related distress arises, try briefly acknowledging it as you would for a friend: "This is hard right now. Lots of people feel this way. What would be kind to do next?" Neff's work offers short exercises that can be used in a few minutes, and many universities offer self-compassion or mindfulness workshops. The goal is not to make the distress disappear but to respond to it without adding self-criticism. Connect your body to your values. Ask what you want your life at university to be about. Most students, asked directly, name things like learning, friendship, adventure, creativity, contributing to causes they care about, preparing for a career, having fun. Very few name "having a particular body". Holding those values in mind makes it easier to notice when body concerns are pulling attention away from what matters, and to choose deliberately to return to it. Two honest objections Two objections to body neutrality come up often, and both deserve a serious answer. The first is that body neutrality sounds like giving up on health. If a student stops paying attention to their body, will they not neglect it? The answer is that body neutrality does not mean ignoring the body. It means paying attention to different things. A student practising body neutrality still notices hunger and eats, notices tiredness and rests, notices stiffness and moves, notices illness and seeks care. What they stop doing is evaluating the body's appearance as a measure of worth. In practice, many people find that they look after their bodies better once they stop being at war with them. Self-care is easier to sustain when it is not driven by self-criticism, and the research on self-compassion described above suggests that kindness toward oneself tends to support healthy behaviour rather than undermine it. The second objection is more personal: what if I genuinely want to change my body? Perhaps a student wants to become stronger, to run further, to recover from an injury or to manage a health condition. Body neutrality has no quarrel with these goals. Building strength, improving fitness and managing health are forms of caring for the body's function, and they fit comfortably within a body-neutral approach. The distinction worth drawing is between goals centred on what the body can do and goals centred on how it looks or how much it weighs. Function-based goals tend to be motivating, measurable in ways that do not involve the mirror, and compatible with eating enough. Appearance-based goals, especially goals about becoming smaller, tend to pull people back into the cycle of restriction and surveillance that Chapter 3 described. Students who feel a strong pull toward changing their size or shape may find it helpful to ask, gently, what they hope that change would give them: confidence, belonging, safety, respect. Those underlying needs are real, and they can often be met more directly, and more reliably, in other ways. Students with medical conditions for which a clinician has recommended specific changes are in a different situation, and that guidance should be followed and discussed openly with the clinician. Even there, a body-neutral stance can help: it keeps the focus on health behaviours and how the person feels, rather than turning every day into a verdict on the body. What changes and what does not Consider a third-year student who has spent two years caught in a cycle of body checking and self-criticism. She begins, with the help of a counsellor, to practise some of these habits. She keeps a function list. She mutes several accounts. She joins a climbing club, where for two hours at a time she thinks about nothing except the next hold. She starts noticing when her inner voice turns harsh and experiments with neutral language. Nothing about her body changes. What changes is how much of her day her body occupies. After a few months, she notices that she no longer thinks about her appearance first thing in the morning. She can eat dinner with friends without calculating. She still has bad body days, especially before events where she knows she will be photographed, but they pass more quickly and do not derail her week. She would not say she loves her body. She would say she has stopped fighting it, and that this has given her back a surprising amount of time and energy. That is the realistic promise of body neutrality. It does not promise that negative thoughts will disappear, that bodies will become beautiful, or that cultural pressures will vanish. It promises something smaller and more durable: that the body can move from the centre of attention to the background, where it can quietly do its work while its owner gets on with living. The next chapter applies this same principle to food, which for many students is the arena in which body concerns become most concrete, and most daily. Chapter 6: Eating Like Someone with a Life Food is where body worries become practical. A student can hold body neutrality as an idea, but three times a day they still have to decide what to eat, and in the dining hall, the shared kitchen or the late-night takeaway queue, the old rules can reassert themselves with surprising force. This chapter is about what a healthy relationship with food looks like in the specific conditions of university life. It does not offer a meal plan, and it contains no numbers to hit. Its aim is to describe a way of eating that keeps food in its proper place: important, pleasurable, nourishing and, for most of the day, not very interesting to think about. The phrase that best captures that aim is eating like someone with a life. A person with a life eats in order to have energy for the things they care about. They eat with friends because friendship matters. They eat foods they enjoy because enjoyment matters. They eat enough, regularly enough, that hunger does not hijack their attention. And they do not treat each meal as a referendum on their worth. Regular, adequate, flexible For most students, a healthy relationship with food rests on three simple principles. None of them requires counting anything. The first is regularity. Eating at reasonably regular intervals across the day, typically three meals and one or more snacks, with no very long gaps, keeps energy steady, supports concentration and prevents the kind of intense hunger that makes eating feel chaotic. Many students' eating becomes irregular at university not because of any decision but because their timetable is irregular. A student with an early lecture may skip breakfast; a student with back-to-back afternoon seminars may miss lunch; a student who studies late may eat most of their food after nine at night. The fix is not a rigid schedule but a loose structure: a rough plan for when meals and snacks will happen on each kind of day, and a few portable foods in a bag for the gaps. The second is adequacy. Eating enough is the foundation on which everything else rests. Chronic under-eating, whether deliberate or the result of busyness and stress, produces predictable effects: fatigue, poor concentration, irritability, feeling cold, disrupted sleep, and, as Chapter 3 described, an intensifying preoccupation with food. Adequacy also includes satisfaction. A meal that technically provides fuel but leaves someone unsatisfied often leads to continued searching for food afterward. Eating foods that are genuinely enjoyable is not an indulgence; it is part of eating adequately. The third is flexibility. Healthy eating is not rigid. It adapts to circumstances: a birthday cake, a spontaneous dinner with friends, a week of exams when cooking is impossible, a trip home where someone else is cooking, a cultural celebration with its own foods. A flexible eater can eat what is available, enjoy it, and move on without guilt or compensation. Rigidity, by contrast, is one of the clearest warning signs that a relationship with food has become strained. When a student finds that they cannot eat a meal they did not plan, or feel intense anxiety when a usual food is unavailable, the rules have started to run the person rather than the other way round. The dietitian and family therapist Ellyn Satter has written for decades about what she calls eating competence, an approach that emphasises positive attitudes toward eating, acceptance of a variety of foods, internal regulation based on hunger and fullness, and the practical skills needed to provide regular meals. Her work is a useful reminder that "healthy eating" is not only about which foods are on the plate. It is also about the attitudes and structures surrounding them. Intuitive eating, and its limits Many students who begin questioning diet culture encounter intuitive eating, an approach developed by the dietitians Evelyn Tribole and Elyse Resch and first set out in their 1995 book Intuitive Eating, now in its fourth edition. The approach is built around ten principles, including rejecting the diet mentality, honouring hunger, making peace with all foods, challenging the internal "food police", discovering the satisfaction of eating, feeling fullness, coping with emotions with kindness, respecting one's body, enjoying movement, and honouring health through what the authors call gentle nutrition. The research on intuitive eating is encouraging. A 2021 meta-analysis by Jake Linardon, Tracy Tylka and Matthew Fuller-Tyszkiewicz, published in the International Journal of Eating Disorders, pooled findings from many studies and found that intuitive eating was associated with lower levels of disordered eating, more positive body image and greater emotional wellbeing. Most of these studies were correlational, meaning they show that intuitive eating and wellbeing tend to go together rather than proving that one causes the other, but the pattern is consistent, and intervention studies have also shown benefits. Intuitive eating has an important limit that students should know about. It relies on the body's hunger and fullness signals, and those signals are not always reliable. After a period of significant restriction, or during an eating disorder, hunger cues can be dulled, distorted or confusing. Some people do not feel hungry even when they urgently need food; others feel intense, unpredictable hunger. In these situations, clinicians usually recommend a period of more structured, "mechanical" eating, following a regular pattern whether or not hunger is felt, until the body's signals recover. Intuitive eating is best understood as a destination rather than a starting point for someone recovering from disordered eating, and it is best pursued with the help of a dietitian experienced in eating disorders. Intuitive eating is also sometimes misunderstood as "eat whatever you want whenever you want", or, more insidiously, as a new method of weight control. Neither is accurate. Its central aim is to restore trust in the body and peace with food, not to produce any particular body size. Students who find themselves using intuitive eating as a covert diet, eating "intuitively" but with the hope of becoming smaller, may notice that the preoccupation has not gone away. It has simply changed its vocabulary. Once eating has become regular and relaxed, there is room for what Tribole and Resch call gentle nutrition: making choices that support health without turning them into rules. In practice this usually means variety across the week rather than perfection at every meal, including fruits, vegetables, whole grains and a range of protein sources when they are available and appealing, and paying some attention to nutrients that young adults commonly fall short on. Students who menstruate, for example, have higher iron needs, and students who eat little or no animal food need a reliable source of vitamin B12. Vegetarian and vegan diets can be entirely healthy and are chosen for many good reasons, including ethics, religion and environmental concern. Clinicians do note, however, that for some people a sudden shift to a highly restrictive way of eating, presented as an ethical or health choice, can also serve as a socially acceptable form of restriction. The useful question is not which foods someone eats but whether their eating is still flexible, adequate and free from fear. A registered dietitian can help students on any pattern of eating make sure their needs are met. Eating in the real conditions of campus Principles are easy. Tuesday is harder. What does regular, adequate, flexible eating look like in a residence hall with a meal plan, or in a shared kitchen with a limited budget and a tired brain? In the dining hall. Dining halls offer enormous choice, which can be liberating but also overwhelming, especially for students who have spent time worrying about food. A simple approach helps. At most meals, aim to include something filling, such as grains, bread, potatoes, rice or pasta; something with protein, such as meat, fish, eggs, beans, tofu or dairy; some fruit or vegetables; and something you actually enjoy. That last element is not optional. Satisfaction is part of nourishment. Students who find the variety stressful can rely on a handful of familiar meals and gradually branch out, without needing to read every label. Students with allergies, coeliac disease or other medical dietary needs should know that most dining services have staff, sometimes including a dietitian, who can help them navigate safely. With an irregular timetable. Take a quick look at the week and identify where the long gaps fall. A granola bar, piece of fruit, handful of nuts, sandwich, yoghurt or similar portable food in a bag can bridge a gap between a morning lecture and an afternoon lab. Eating something before a late-night study session, and having something available during it, prevents the kind of ravenous late-night eating that many students later feel bad about. On a budget. Eating well does not require expensive foods. Oats, rice, pasta, eggs, beans, lentils, frozen vegetables, bananas, peanut butter, bread, tinned fish and seasonal produce are inexpensive and versatile. Cooking in batches with friends can reduce cost and effort while adding company. Students living off campus for the first time often benefit from a few basic recipes they can make without thinking: a pasta dish, a stir-fry, a soup, a rice-and-beans bowl, eggs on toast. Many campuses offer free cooking classes, often through health promotion or residential life. When tired or stressed. During exams or deadline weeks, the aim is simply to keep eating. Convenience foods, takeaway, cereal for dinner, a sandwich eaten at the desk: all are fine. A student who eats a bowl of cereal at eleven at night during finals is not failing at nutrition. They are feeding a brain that is working hard. Perfectionism about food during high-stress periods is counterproductive; it adds a further demand at the moment when there is least capacity to meet it. With friends. Food is one of the main ways students build community. Accepting invitations to eat, whether at the dining hall, a friend's flat or a late-night food run, is valuable in its own right, regardless of what is eaten. Students who find themselves regularly declining food-related social events because of anxiety about eating are losing something important and may benefit from support. When food is scarce Not every student's relationship with food is shaped mainly by body concerns. For many, the pressing problem is not having enough. Research in the United States, including large surveys conducted by the Hope Center for Student Basic Needs, has found that food insecurity, meaning limited or uncertain access to enough food, is common among college students, particularly among community college students, students who are parents, first-generation students and students from low-income backgrounds. The experience is often invisible. A student may be skipping meals not because of a diet but because their money has run out before the end of the month. Food insecurity and body image are connected in ways that are often overlooked. A 2020 review by Vivienne Hazzard, Katie Loth, Laura Hooper and Carolyn Becker in Current Psychiatry Reports examined emerging evidence linking food insecurity with eating disorders, including binge eating. Periods of scarcity followed by periods of availability can produce cycles of restriction and overeating similar to those produced by dieting, and the stress of not having enough food can intensify preoccupation with it. Students experiencing food insecurity may also find that the diet-culture language surrounding them, about being "good" for not eating, adds shame to genuine hardship. Many universities now have food pantries, meal-swipe sharing programmes, emergency grants and staff who can help students access public benefits. In the United States, some students are eligible for the Supplemental Nutrition Assistance Program (SNAP), although student eligibility rules are specific and can be complicated, so it is worth asking a campus basic-needs office or financial aid office for help. Systems in other countries differ, and students elsewhere should ask their student services or students' union what support exists locally. Using these resources is not a failure. Food is a basic need, and students cannot learn well without it. Alcohol, food and safety Alcohol is part of social life on many campuses, and its relationship with food deserves a brief, direct word. Some students, influenced by diet culture, restrict their eating before or on days when they plan to drink, in an attempt to compensate. This practice is dangerous. Drinking on an empty stomach causes blood alcohol levels to rise faster and higher, increasing the risk of alcohol poisoning, injury, blackouts and assault. It also combines two forms of harm, under-eating and heavy drinking, in a way that clinicians who work with students take seriously. Eating a proper meal before drinking is one of the simplest and most effective safety measures there is. If someone who has been drinking cannot be woken, is breathing very slowly or irregularly, has blue-tinged or pale, clammy skin, is vomiting while not fully conscious, or is having a seizure, these are signs of possible alcohol poisoning and a medical emergency. Call emergency services immediately (911 in the United States; the number differs in other countries), stay with the person, keep them on their side, and do not leave them to "sleep it off". Many universities have medical amnesty policies designed to encourage students to call for help without fear of disciplinary consequences. Emotional eating and the full range of reasons to eat Diet culture often treats eating for any reason other than physical hunger as a problem. But people eat for many reasons: hunger, pleasure, celebration, comfort, connection, boredom, tradition, habit, convenience. Eating a bowl of noodles after a hard day because it feels comforting is a normal human behaviour, not a failure. Emotional eating becomes a concern mainly when food is the only way a person has of coping with difficult feelings, or when eating feels out of control and is followed by intense distress. In those cases, the most useful response is not stricter rules about food, which tend to make the pattern worse, but broadening the range of ways to cope: talking to someone, moving, resting, writing, getting outside, doing something absorbing. If eating regularly feels out of control, or if episodes of eating are followed by shame and attempts to compensate, those are signs worth discussing with a clinician, as Chapter 8 explains. Movement without the ledger Finally, a word about exercise, which diet culture tends to fuse with eating. When movement is understood primarily as a way to earn food or burn it off, it becomes a form of accounting, and like most accounting it tends toward anxiety. Movement has many benefits that have nothing to do with body size: improved mood, reduced stress, better sleep, stronger bones and muscles, and social connection. The most sustainable movement is the kind a person enjoys. For some students that is running or lifting; for others it is dancing, cycling, climbing, team sports, swimming, yoga or walking across campus with a friend. A useful test is whether movement would still feel worthwhile if it had no effect on appearance at all. If the answer is no, it may be worth exploring other kinds. It is also worth watching for signs that exercise has become compulsive: feeling unable to skip a session even when ill or injured, exercising to compensate for eating, feeling intense guilt or anxiety when a session is missed, or organising life around exercise to the exclusion of other things. These are recognised warning signs of disordered eating and are discussed further in Chapters 7 and 8. Consider a first-year student who arrives with a detailed set of food rules learned from online content: no eating after a certain hour, no bread, a strict gym schedule. By October he is exhausted, irritable and thinking about food constantly. A dietitian at the campus health centre suggests an experiment: for four weeks, eat three meals and two snacks a day, include foods he enjoys at every meal, and exercise only when he feels like it. He is sceptical, even frightened. But within a few weeks he finds his energy returning, his concentration improving and, to his surprise, his preoccupation with food fading. The food rules had promised control. What they had actually delivered was a mind that could think of little else. Regular, adequate, flexible eating gave him his attention back. Chapter 7: Not One Kind of Student The freshman fifteen has an implied audience. It was born in a magazine for teenage girls, and for most of its history it has conjured a particular image: a young, white, middle-class woman in a dormitory, anxious about becoming larger. That image has shaped not only how the myth is told but also how body image problems in general are imagined, researched and treated. It has also made it easier to overlook the many students whose struggles with food and body look different. This chapter widens the frame. Body image pressures and eating disorders affect students of every gender, sexuality, ethnicity, body size, background and level of ability. The pressures take different forms for different groups, and some students face barriers to recognition and help that others do not. Understanding those differences matters for two reasons. It helps students recognise their own experience when it does not match the stereotype, and it helps friends, staff and clinicians notice problems they might otherwise miss. A note of caution applies throughout. Describing patterns that are more common in particular groups does not mean every member of that group shares them. The aim is not to assign anyone a set of problems based on identity but to make visible experiences that the dominant story tends to hide. Men and the pressure to be bigger For many young men, body pressure does not point toward being smaller. It points toward being bigger, leaner and more muscular at the same time: broad shoulders, visible muscle definition, low body fat. This ideal is heavily promoted through fitness content, advertising, films and games, and it can be just as unrealistic for most bodies as the thin ideal promoted to women. Men's body image concerns often go unrecognised, including by the men themselves. A young man who spends hours at the gym, follows rigid eating rules, consumes large amounts of protein supplements and feels intense distress if he misses a session may be admired by peers as disciplined. The possibility that he is struggling may not occur to anyone. Researchers who study male eating disorders have repeatedly pointed out that diagnostic tools and public awareness have been built largely around female experience, emphasising the pursuit of thinness, so that muscle-oriented disordered eating can slip through unnoticed. In a 2017 review in Clinical Psychology Review, Stuart Murray and colleagues described male eating disorders as an "enigma" in part for exactly this reason: they are under-recognised, under-researched and often presented differently than in women. One condition deserves particular mention. Muscle dysmorphia, classified in the major diagnostic manual as a form of body dysmorphic disorder, involves a persistent preoccupation with the idea that one's body is too small or insufficiently muscular, even when others see a muscular body. It can lead to compulsive exercise, rigid eating, social withdrawal and, in some cases, the use of anabolic steroids or other performance-enhancing substances, which carry serious health risks. It is more common in men but not exclusive to them. Men also face distinctive barriers to seeking help. Stereotypes that eating disorders are a "women's problem", together with broader norms that discourage men from acknowledging vulnerability, can make it feel impossible to raise the issue. Men who do seek help sometimes report that clinicians initially dismissed or misread their symptoms. It is important for young men to know that eating disorders and serious body image problems affect men, that they are not a sign of weakness, and that effective help exists. Athletes and the cost of under-fuelling Student athletes face a particular combination of pressures. Their bodies are scrutinised by coaches, teammates and sometimes spectators. In some sports, such as gymnastics, distance running, diving, figure skating, dance and rowing, leanness is believed to confer a performance or aesthetic advantage. In others, such as wrestling, rowing and combat sports, athletes compete in weight categories and may feel pressure to reach a specific weight before competition. Athletes are also, by their nature, often highly disciplined, perfectionistic and willing to endure discomfort, traits that serve them in sport but can also make restriction easier to sustain. Sports medicine now has a name for the consequences of not eating enough to support training. The International Olympic Committee has published a series of consensus statements on what it calls Relative Energy Deficiency in Sport, most recently updated in 2023 by Margo Mountjoy and colleagues in the British Journal of Sports Medicine. The core idea is that when an athlete's energy intake is too low to cover both the demands of training and the body's basic functions, a wide range of systems can be affected: menstrual function, bone health, the immune system, metabolism, cardiovascular health, mood and, ironically, athletic performance itself. Low energy availability can occur through deliberate restriction, but it can also happen inadvertently, when an athlete simply does not realise how much food their training requires or does not have time to eat enough around a demanding schedule. Among the warning signs are periods that become irregular or stop, repeated stress fractures or injuries that heal slowly, frequent illness, persistent fatigue, declining performance despite training, and mood changes. Missing periods is sometimes treated in sporting culture as a normal consequence of hard training. It is not. It is a sign that the body is not getting enough energy and should be discussed with a doctor. Many university athletic departments now have access to sports dietitians, team physicians and mental health professionals who understand these issues. Athletes who are worried about their own eating, or about a teammate, can raise concerns with these staff. Coaches also have a role: research and professional guidance in sports medicine increasingly recommend that coaches avoid commenting on athletes' body size or weight and instead focus on performance, health and wellbeing. LGBTQ+ students Research has consistently found that some groups of LGBTQ+ people experience higher rates of eating disorder symptoms than their heterosexual and cisgender peers. A 2015 study by Elizabeth Diemer and colleagues, published in the Journal of Adolescent Health and drawing on a large national sample of American college students, found that transgender students reported substantially higher rates of eating disorder diagnoses and of compensatory behaviours than cisgender students, and that sexual minority students also reported elevated rates compared with heterosexual peers. Researchers often explain these patterns through the concept of minority stress: the additional, chronic stress that comes from stigma, discrimination, rejection and the need to conceal or manage one's identity. That stress can increase vulnerability to many mental health difficulties, including disordered eating. Some communities also carry particular body ideals. Gay and bisexual men, for example, may encounter intense pressure around leanness and muscularity within parts of their social world. For transgender and nonbinary students, the relationship between body and identity has additional layers. Some people report using restriction or other disordered eating behaviours to suppress secondary sex characteristics or to shape their bodies toward a form that feels more aligned with their gender. Body dissatisfaction in this context may be closely tied to gender dysphoria, and clinicians increasingly recognise that access to gender-affirming care and support can be an important part of reducing distress. For these students, finding clinicians who are knowledgeable and affirming about both gender and eating concerns makes a significant difference. Many campuses have LGBTQ+ resource centres that can help students identify such clinicians. Culture, race and the myth of who is affected A persistent stereotype holds that eating disorders mainly affect affluent white women. The stereotype is false, and it causes harm. When clinicians, families and students themselves believe it, eating disorders in other groups are more likely to go unrecognised and untreated. Research has found eating disorders across all ethnic and racial groups, and has documented that people of colour with eating disorders are less likely to be asked about eating symptoms or referred for treatment. Body ideals also vary across cultures and communities, and students may be navigating several at once. A student might feel pressure from a mainstream culture that promotes thinness, from a family culture with its own expectations about appearance and eating, from a peer group with a different ideal again, and from beauty standards shaped by colourism or Eurocentric features that have little to do with body size. Hair, skin tone and facial features can all become sites of appearance pressure alongside shape and weight. Diet culture can also carry cultural bias. The language of "clean eating" and the lists of foods labelled healthy or unhealthy are often drawn from a narrow cultural tradition, and foods central to other traditions, such as rice, tortillas, bread, plantains or noodles, may be implicitly or explicitly framed as problems. A student who has grown up eating foods that carry family memory and cultural identity may find those foods quietly disparaged in university health messaging or online content. Rejecting one's cultural food in the name of health can mean losing a connection to family and community. International students face their own version of this. Moving to a country where familiar foods are unavailable, expensive or unfamiliar to dining services can disrupt eating significantly. Homesickness often expresses itself through food. Students in this situation may benefit from seeking out cultural student associations, local shops that stock familiar ingredients and opportunities to cook with others from similar backgrounds. Continuing to eat familiar foods is not a failure to adapt. It is a source of stability during a major transition. Students in larger bodies Students in larger bodies experience the freshman fifteen and diet culture differently. For them, the message is not a warning about a possible future but a judgement about the present. They are often the implied target of health campaigns, the subject of unsolicited advice, and the object of assumptions about their eating, activity and character. Weight stigma, the negative attitudes and discrimination directed at people because of their body size, is extensively documented. A 2009 review by Rebecca Puhl and Chelsea Heuer in Obesity found evidence of weight bias in employment, education, healthcare and interpersonal relationships. More recent work has examined the health consequences of that stigma. In a 2018 paper in BMC Medicine, A. Janet Tomiyama and colleagues argued that weight stigma functions as a chronic stressor, with physiological and behavioural effects, including increased stress hormones, avoidance of healthcare and exercise settings, and disordered eating, that can themselves harm health. The paradox they highlight is that stigma, often justified as a motivator for health, tends to undermine it. Weight bias in healthcare is a particular concern. Students in larger bodies often report that clinicians attribute unrelated symptoms to weight, recommend weight loss without examining other causes, or make comments that leave them reluctant to return. Some avoid medical care altogether as a result. Students who have had these experiences are entitled to ask for their concern to be investigated in the same way it would be for anyone else, to ask whether weight is relevant to a particular problem, and to seek a different clinician if needed. It is also important to understand that eating disorders occur in people of all sizes. A person in a larger body can be seriously restricting their eating and experiencing dangerous medical consequences. Diagnostic manuals now recognise a presentation, often called atypical anorexia nervosa, in which a person shows the psychological features and behaviours of anorexia but their weight is not low. Because the person does not "look" ill, and may even be praised for weight loss, the condition is frequently missed. Anyone whose eating has become severely restrictive deserves assessment and care, regardless of body size. Finally, students in larger bodies deserve access to all the ordinary pleasures of university life without having to earn them. Joining a sports team, going to the gym, eating in the dining hall, wearing whatever clothes they like, dating and being photographed are not rewards for having a particular body. They are part of being a student. Chronic illness, disability and medical diets Some students have medical conditions that require specific attention to food: coeliac disease, food allergies, diabetes, inflammatory bowel disease, and others. For these students, attention to food is a medical necessity, not diet culture. But the line between necessary vigilance and disordered eating can sometimes blur, and research has found that some medical conditions involving dietary management are associated with a higher risk of eating disorders. Type 1 diabetes is one important example. Clinicians and researchers have documented that some people with type 1 diabetes deliberately manipulate their insulin to influence their weight, a practice that is extremely dangerous and can lead to serious complications. Students with diabetes who find that body image concerns are affecting how they manage their condition should raise this with their diabetes care team, who are increasingly aware of the issue. Disabled students may also face particular body image challenges, including assumptions about their bodies, limited access to physical activity spaces, and appearance ideals that exclude bodies that move or look different. Body neutrality, with its emphasis on what the body does in the life of its owner rather than whether it matches an ideal, may be particularly helpful here, though function looks different for every person, and no body needs to be measured against a standard of "normal" function to be worthy of respect. Students arriving in recovery One group is easy to overlook because their difficulties began before university: students who arrive already in treatment for an eating disorder, or in recovery from one. For these students, the move to university can be a period of particular vulnerability. The structures that supported recovery at home, such as family meals, a familiar treatment team, predictable routines and people who knew what to look for, may all disappear at once, just as the new environment introduces irregular schedules, social pressure around food, and the freshman fifteen. This does not mean that students in recovery should not go to university, and many thrive there. It does mean that planning ahead matters. Clinicians who work with young people in recovery often recommend that students, together with their current treatment team, think through several questions before arrival. Who will provide ongoing treatment at or near the university, and has contact been made before term starts? What does a regular pattern of eating look like given the dining options and timetable, and what is the plan for busy days? What are the early warning signs of relapse for this particular person, and who will they tell if they notice them? Is there a trusted person on campus, perhaps a counsellor, doctor or residential staff member, who knows the situation? Would academic or housing accommodations help, such as a room with access to a kitchen or flexibility around meal times? Many universities can arrange accommodations for students with eating disorders through disability or accessibility services, and campus counselling centres are often willing to coordinate with a student's existing clinicians. Students do not have to disclose their history to anyone they do not wish to tell. But those who arrange support in advance usually find it much easier to use when they need it, rather than trying to find help for the first time in the middle of a difficult term. Friends and roommates of students in recovery can help most simply by being ordinary companions around food: eating together, not commenting on what anyone eats, avoiding diet talk, and treating meals as social occasions rather than tests. What this means for everyone The single most important lesson of this chapter is that there is no typical student with body image struggles and no typical person with an eating disorder. The stereotype of who is affected acts as a filter, and people who do not match it are more likely to suffer longer before receiving help. For students, this means trusting their own experience even when it does not look like the familiar story. A young man who cannot stop exercising, an athlete whose periods have stopped, a student in a larger body who has been restricting for months, a transgender student using food to manage dysphoria, an international student who has stopped eating since arriving: each of these is a situation worth taking seriously. For friends and staff, it means widening the frame of concern. The next chapter describes the warning signs of eating disorders in detail, along with guidance on how to raise concerns and where to find help. Those signs apply across all the groups described here. Chapter 8: When It Becomes More Than Worry Most students who worry about their bodies do not have an eating disorder. Body dissatisfaction is common, and many people move through periods of heightened concern, especially during transitions like the start of university, without their eating becoming seriously disordered. But for some students, worry deepens into something else. Rules about food multiply and harden. Thoughts about eating and body shape come to occupy most of the day. Behaviours that began as attempts at control start to feel impossible to stop. At that point, the problem is no longer a matter of attitude or information. It is a health condition that deserves professional care. This chapter is about recognising that point and knowing what to do. It describes the main types of eating disorder, the warning signs that something more serious is happening, how to support a friend, and how to find help. It is written for students who may be worried about themselves and for those who are worried about someone else. If you are in either position, you do not need to be certain that something is wrong in order to seek advice. Uncertainty is a perfectly good reason to ask. A continuum, not a switch It helps to think of eating and body concerns as a continuum rather than a simple division between "fine" and "disordered". At one end is a relatively relaxed relationship with food and body, in which eating is regular, flexible and mostly unremarkable, and appearance occupies a modest share of attention. Further along is a zone of heightened concern: more body checking, some food rules, occasional guilt after eating, more time spent thinking about appearance. Further still is disordered eating: rigid rules, significant restriction or episodes of eating that feel out of control, compensatory behaviours, and a relationship with food that is causing distress or interfering with life. At the far end are clinical eating disorders, which are diagnosable mental illnesses with serious physical and psychological consequences. People can move along this continuum in both directions. A student in the zone of heightened concern during their first term may move back toward a relaxed relationship as they settle in, especially if they encounter supportive friends and ideas like those in this book. Another student may move further toward disorder, particularly under stress, isolation or pressure from their environment. The earlier movement toward disorder is noticed and addressed, the easier it usually is to reverse. Understanding eating disorders The major diagnostic manuals describe several types of eating disorder. What follows is a brief, general description intended to help recognition, not diagnosis. Only a qualified clinician can diagnose an eating disorder. Anorexia nervosa involves persistent restriction of food intake leading to significantly low body weight for the person's age, sex and development, together with intense fear of weight gain and a disturbance in how body weight or shape is experienced. As Chapter 7 noted, a related presentation, often called atypical anorexia, involves the same features without low weight, and it can be just as medically dangerous. Bulimia nervosa involves recurrent episodes of binge eating, meaning eating an unusually large amount of food in a discrete period with a sense of loss of control, followed by repeated behaviours intended to compensate, such as purging, misuse of medications, fasting or excessive exercise. Self-worth is heavily influenced by body shape and weight. People with bulimia are often not underweight, which means the illness can remain hidden for a long time. Binge eating disorder involves recurrent episodes of binge eating with a sense of loss of control and marked distress, without regular compensatory behaviours. It is the most common eating disorder in many population studies and is frequently associated with shame and secrecy. It is not a matter of willpower, and dieting tends to make it worse. Avoidant/restrictive food intake disorder, often abbreviated as ARFID, involves restricted eating that is not driven by body image concerns but by other factors, such as extreme sensitivity to the sensory qualities of food, fear of choking or vomiting, or a general lack of interest in eating. It can lead to significant nutritional deficiency and interference with daily life. Other specified feeding or eating disorder is a category for eating disorders that cause significant distress or impairment but do not fit neatly into the other categories. It includes atypical anorexia and other presentations. Being in this category does not mean a disorder is less serious. Eating disorders are serious illnesses. A widely cited 2011 meta-analysis by Jon Arcelus and colleagues in the Archives of General Psychiatry found that people with eating disorders, and particularly anorexia nervosa, had markedly elevated mortality rates compared with the general population, from both medical complications and suicide. Eating disorders can affect almost every organ system, including the heart, bones, digestive system, hormones and brain. They are also treatable, and many people recover fully, particularly when they receive appropriate treatment early. Among college students, eating disorder symptoms are common and often go untreated. In the 2011 study by Eisenberg and colleagues mentioned in the introduction, 13.5 per cent of undergraduate women and 3.6 per cent of undergraduate men screened positive for eating disorder symptoms, and only around one in five of those who screened positive had received mental health treatment in the past year. The screen used in that study does not diagnose eating disorders, but the finding illustrates a gap between how many students are struggling and how many get help. Warning signs Eating disorders often develop gradually, and early signs can be easy to miss or explain away, especially in a culture where dieting and intense exercise are praised. Table 4 sets out some of the signs that may indicate a developing problem. No single sign confirms an eating disorder, and some signs have other explanations. But a cluster of them, especially if they are increasing over time, is worth taking seriously. Table 4. Possible warning signs of an eating disorder. Area What you might notice in yourself What a friend might notice Thoughts Constant thoughts about food, weight or shape; self-worth tied to eating or appearance Frequent talk about food, dieting or body; distress after eating Eating Rigid rules; cutting out foods or food groups; eating that feels out of control Skipping meals; avoiding eating with others; unusual rituals around food Compensation Urges to make up for eating through exercise, fasting or other means Disappearing after meals; compulsive exercise, even when ill or injured Body Tiredness, dizziness, feeling cold, missed periods, stomach problems Noticeable changes in weight in either direction; fainting; frequent illness Mood and life Anxiety, irritability, low mood, withdrawal, secrecy Pulling away from friends and activities; declining grades; defensiveness about food A few further points are worth emphasising. Eating disorders are often accompanied by secrecy and shame, so a person may go to considerable lengths to hide their behaviours. They also commonly occur alongside other mental health difficulties, such as depression, anxiety, obsessive-compulsive symptoms and substance use. And a person with an eating disorder may not recognise that they are unwell; the illness itself can distort how they see their situation. Some signs indicate a medical emergency. Fainting, chest pain, a very slow, fast or irregular heartbeat, confusion, severe weakness, vomiting blood or thoughts of suicide require immediate help. In the United States, call 911 for a medical emergency or call or text 988, the Suicide and Crisis Lifeline, for a mental health crisis. In other countries, call your local emergency number. Campus security and residential staff can also help summon assistance. Supporting a friend Many students first become aware of an eating disorder in someone close to them: a roommate, teammate, partner or friend. Knowing how to raise the subject is difficult, and fear of saying the wrong thing often leads people to say nothing at all. The following guidance, consistent with advice from eating disorder organisations and clinicians, can help. Choose the right time and place. Find a private, calm moment when neither of you is rushed, stressed or around food. Avoid raising concerns at a meal, just after an argument, or in front of others. Speak from your own experience. Use "I" statements that describe what you have noticed and how you feel, rather than accusations or diagnoses. "I've noticed you haven't been eating with us lately, and I've been worried about you" is easier to hear than "You have an eating disorder." Focus on feelings and behaviours, not weight or appearance. Avoid comments about the person's body, even well-meaning ones such as "You look too thin". These can reinforce the focus on appearance and may be heard as a challenge or even as encouragement. Instead, talk about what you have observed in their mood, energy and behaviour. Expect a range of reactions. The person may deny there is a problem, become angry or defensive, or seem relieved. All of these are common. Denial does not mean you were wrong to raise the concern, and you do not need to resolve everything in a single conversation. Letting them know you care and are available to talk again is valuable in itself. Encourage professional help. Offer information about campus services and, if they are willing, offer to help them make an appointment or go with them. Avoid ultimatums unless there is an immediate safety concern. Do not become the food police. Monitoring what a friend eats, commenting on their plate or trying to make them eat usually increases conflict and shame. Your role is to be a friend, not a clinician. Take care of yourself. Supporting someone with an eating disorder can be stressful and upsetting. Talk to someone you trust, and consider speaking to a counsellor yourself. You cannot fix another person's illness, and you are not responsible for their recovery. Know when to involve others. If you believe your friend is in immediate danger, whether from medical complications or risk of suicide, contact emergency services. If you are a student living in university housing, residential staff can also advise. In non-emergency situations, you can speak to a counsellor at your campus counselling centre for advice about how to help, even if your friend is not yet ready to seek help themselves. Getting help For students worried about themselves, the most important step is the first one: telling someone. That might be a doctor, a campus counsellor, a trusted friend, a family member or a helpline. Many people with eating disorders describe years of struggling alone before telling anyone, and many say that the relief of finally speaking was significant in itself. Most universities offer free or low-cost counselling and health services to enrolled students. A good first step is often an appointment with a campus health centre doctor or nurse, who can assess physical health, or with a counsellor, who can assess psychological wellbeing. Some campuses have staff who specialise in eating concerns or can refer to a registered dietitian experienced in eating disorders. Treatment is often provided by a team that includes a therapist, a dietitian and a doctor. Many students hesitate to book an appointment because they do not know what to say, or fear they will not be taken seriously. It can help to know that you do not need to use clinical language or be sure of what is wrong. Something as simple as "I've been having a hard time with food and I'm worried about it" or "I think about my eating and my body most of the day and it's getting in the way" is enough to begin. Some students find it easier to write a few notes beforehand, or to bring a trusted friend to the appointment. If you are worried about being dismissed, perhaps because you do not fit the stereotype described in Chapter 7, it is reasonable to say so directly: "I know I might not look like someone with an eating problem, but I'm struggling." A first appointment usually involves questions about eating patterns, thoughts about food and body, mood, sleep, physical symptoms and how things are affecting daily life. A doctor or nurse may check vital signs such as heart rate and blood pressure, and may order blood tests, because eating disorders can affect the body in ways that are not visible from outside. None of this is a test of whether you are "sick enough". Clinicians who work with eating disorders are generally clear that anyone whose relationship with food is causing distress deserves help, whatever their weight and however long the problem has lasted. If the first person you see does not respond helpfully, it is worth trying someone else. A single unhelpful appointment says more about that appointment than about whether you deserve care. Several forms of treatment have good evidence. For adults, enhanced cognitive behavioural therapy, known as CBT-E and developed by Christopher Fairburn and colleagues, has been shown to be effective for many people with eating disorders, particularly bulimia nervosa and binge eating disorder, and it is also used for anorexia. For adolescents and younger students living with family, family-based treatment has strong evidence for anorexia nervosa. Other approaches, including other forms of psychotherapy and specialist supportive clinical management, also have a role. Treatment is not one-size-fits-all, and a good clinician will discuss options. In the United States, eating disorder treatment is organised into levels of care, from outpatient therapy through intensive outpatient programmes, partial hospitalisation, residential treatment and inpatient hospitalisation, depending on medical and psychological needs. Access to these services can depend on insurance coverage and location, and navigating them can be confusing. Structures, terminology and access differ considerably in other countries, and students outside the United States should ask their campus health services or general practitioner about local pathways. Students who need more intensive treatment than can be provided alongside study may need to take a leave of absence. This can feel like failure, but it is not. Many students who step away to recover return to complete their studies successfully. Universities typically have processes for medical leave and for academic accommodations for students managing health conditions, often through disability or accessibility services. Speaking to these offices early can make the process smoother. Beyond campus, several organisations can help. In the United States, the National Alliance for Eating Disorders operates a helpline at (866) 662-1235, available on weekdays and staffed by licensed clinicians, which helps people find treatment and support resources; it is not a crisis line. The organisation also offers support groups. ANAD, the National Association of Anorexia Nervosa and Associated Disorders, operates a free helpline at 1-888-375-7767 on weekdays that provides emotional support and referrals, and runs free peer support groups for people navigating eating and body image difficulties. For crisis support at any hour, the 988 Suicide and Crisis Lifeline can be reached by calling or texting 988. Helpline hours and services can change, so it is worth checking each organisation's website for current details. In other countries, national eating disorder organisations provide similar support. Examples include Beat in the United Kingdom, the National Eating Disorder Information Centre (NEDIC) in Canada, and the Butterfly Foundation in Australia. Students elsewhere can ask their university health or counselling service which organisations operate locally. Recovery is possible It is worth ending this chapter with a clear statement: people recover from eating disorders. Recovery can take time, and it rarely follows a straight line, but many people go on to have relaxed, flexible relationships with food and their bodies and full, satisfying lives. Early help improves the chances of recovery and shortens the road. Consider a fourth-year student who, looking back, can see that her eating disorder began in her first term, with a vague worry about the freshman fifteen and a few rules about what she would and would not eat in the dining hall. By her second year the rules had taken over. A friend who noticed her withdrawing gently raised the concern, and after several months of hesitation she went to the campus counselling centre. Treatment was hard. It involved a therapist, a dietitian and regular medical checks, and at one point a semester away from classes. But two years later, she eats with friends without thinking much about it, has returned to the sport she loved, and describes the time she used to spend on food and body as something she got back. She sometimes says that the most important thing anyone did for her was to notice, and to say something kindly. If you recognise yourself in this chapter, you do not have to be certain, and you do not have to wait until things are worse. Tell someone. If you recognise a friend, you do not need the perfect words. Tell them you care. Conclusion: The Year You Get Back The chapters of this book have moved from a single phrase to a whole environment: from a magazine cover line in 1989 to the dining hall, the gym, the phone, the clinic and the conversations students have with each other late at night. Having followed that path, it is possible to see something that is hard to see at the start. The freshman fifteen was never really a claim about bodies. It was a claim about attention, about where a young adult's attention belongs during one of the most formative years of their life. The phrase answered: on the body, watchfully. Everything in this book argues for a different answer. That shift has consequences that are worth drawing out, because they change what counts as a good first year, what institutions owe their students, and what questions remain unresolved. A different measure of a good year If the freshman fifteen frames the first year as a test of bodily stability, then success means leaving university with roughly the same body one arrived with. The evidence in Chapters 1 and 2 shows why that measure is meaningless: bodies change in early adulthood whether or not people go to university, and fluctuation is noise rather than information. But the argument of Chapters 3 through 6 goes further. It shows that the effort to hold the body still is itself costly, because the vigilance it requires consumes exactly the resources a first year is meant to build: attention, energy, curiosity, friendship, flexibility. So the measure should change. A good first year is not one in which the body stayed the same. It is one in which food stayed in its place, regular, adequate, flexible and enjoyable, so that the mind was free for other things. It is one in which a student could eat with new friends without calculating, move in ways they enjoyed, sleep reasonably, and have a bad body day without losing a week to it. By this measure, a student whose body changed considerably but who spent the year absorbed in learning and friendship has done well. A student whose body stayed exactly the same through constant surveillance has paid a high price for an outcome that did not matter. This is not a consolation prize. It is the more accurate account of what university is for. What institutions owe students One of the quieter lessons of the preceding chapters is that individual effort can only do so much. A student can mute accounts, practise body neutrality and eat regularly, but if the dining hall labels every dish as a moral choice, the orientation talk jokes about the freshman fifteen, the coach comments on bodies, the gym runs "transformation" challenges and the health campaigns focus on weight, that student is swimming against a strong current. The research on dieting, on fat talk, on weight stigma and on social comparison all points in the same direction: environments shape body image, and changing environments is often more effective than asking individuals to resist them. That implies concrete things universities can do. They can retire the freshman fifteen from orientation materials, residential programming and health messaging, and replace it with guidance about the things that actually shape the first year: routines, sleep, regular meals, connection and knowing where to find help. They can make programmes with strong evidence, such as the Body Project, widely available. They can train coaches, trainers and residential staff to avoid commenting on students' bodies and to recognise warning signs. They can move scales out of open gym areas and ensure that clinical weighing is done only when medically necessary and with sensitivity. They can fund food pantries and basic-needs support so that no student's eating is shaped by scarcity. And they can make sure that counselling services are adequately resourced to see students with eating concerns promptly, because the gap between the number of students struggling and the number receiving help, documented by researchers for well over a decade, remains one of the most serious problems in this area. None of these changes is expensive or radical. They simply remove sources of pressure that serve no one. What remains unsettled Honesty requires acknowledging what this book cannot resolve. The evidence base for body neutrality as a distinct approach is still thin. The underlying ideas, such as functionality appreciation and self-compassion, have encouraging experimental support, but "body neutrality" itself has not been extensively studied as a named intervention, and it remains possible that different people benefit from different orientations. Some may find body positivity more helpful; others may need more structured clinical approaches. The practices in Chapter 5 are best understood as reasonable, evidence-informed experiments rather than proven prescriptions. The long-term effects of social media on body image are also still being worked out. Experimental studies show short-term harms from certain kinds of content, and early studies of reducing use are promising, but platforms change faster than research can track them, and the effects appear to differ considerably between people. There is also a live debate in medicine and public health about how to talk about weight and health. Weight-neutral approaches, which focus on health behaviours rather than weight, have gained substantial support, particularly among clinicians working with eating disorders. At the same time, many clinicians continue to regard weight as a relevant health indicator for some individuals. The arrival and rapid spread of new weight-loss medications in recent years has added a further complication. For some people those medications are prescribed for genuine medical reasons, and that is a matter for individual clinical judgement. But their cultural visibility has also intensified public conversation about thinness in ways that students cannot help noticing. How this will affect young people's body image, and how universities and clinicians should respond, are genuinely open questions. Acknowledging these uncertainties does not weaken the core argument. It strengthens it. Where the science is unsettled, the case for not organising one's first year around bodily vigilance becomes more compelling, not less. What is well established, that dieting rarely achieves its promise, that weight stigma harms health, that body surveillance consumes attention, and that eating disorders are serious and treatable, is enough to act on. What to do differently If the argument of this book is right, a few things follow for anyone who spends time around students. For students themselves: when someone says "freshman fifteen", recognise the template and decline it. Eat regularly and enough. Pay attention to how you feel, not how you look. Protect your attention online. Notice when food or body starts taking up more room than it should, and do not wait until you are certain to talk to someone. For friends: stop commenting on bodies, including compliments on weight loss. Decline fat talk. Notice when someone is pulling away, and say something kindly. For parents and family: replace the old warning with a different send-off. Something like: "Your routines will change a lot this year. Try to eat regularly, sleep when you can, and find your people. And if anything ever feels hard, with food or anything else, you can always tell me." That last sentence is, in a way, the whole book. The first year of university is too important to spend watching a body. It is better spent living in one. Notes Albertson, E. R., Neff, K. D., and Dill-Shackleford, K. E. (2015). Self-compassion and body dissatisfaction in women: a randomized controlled trial of a brief meditation intervention. Mindfulness, 6, 444-454. Alleva, J. M., Martijn, C., Van Breukelen, G. J. P., Jansen, A., and Karos, K. (2015). Expand Your Horizon: a programme that improves body image and reduces self-objectification by training women to focus on body functionality. Body Image, 15, 81-89. Arcelus, J., Mitchell, A. J., Wales, J., and Nielsen, S. (2011). Mortality rates in patients with anorexia nervosa and other eating disorders: a meta-analysis of 36 studies. Archives of General Psychiatry, 68(7), 724-731. Cohen, R., Fardouly, J., Newton-John, T., and Slater, A. (2019). #BoPo on Instagram: an experimental investigation of the effects of viewing body positive content on young women's mood and body image. New Media & Society, 21(7), 1546-1564. Diemer, E. W., Grant, J. D., Munn-Chernoff, M. A., Patterson, D. A., and Duncan, A. E. (2015). Gender identity, sexual orientation, and eating-related pathology in a national sample of college students. Journal of Adolescent Health, 57(2), 144-149. Eisenberg, D., Nicklett, E. J., Roeder, K., and Kirz, N. E. (2011). Eating disorder symptoms among college students: prevalence, persistence, correlates, and treatment-seeking. Journal of American College Health, 59(8), 700-707. Fardouly, J., Diedrichs, P. C., Vartanian, L. R., and Halliwell, E. (2015). Social comparisons on social media: the impact of Facebook on young women's body image concerns and mood. Body Image, 13, 38-45. Festinger, L. (1954). A theory of social comparison processes. Human Relations, 7(2), 117-140. Fredrickson, B. L., and Roberts, T.-A. (1997). Objectification theory: toward understanding women's lived experiences and mental health risks. Psychology of Women Quarterly, 21(2), 173-206. Fredrickson, B. L., Roberts, T.-A., Noll, S. M., Quinn, D. M., and Twenge, J. M. (1998). That swimsuit becomes you: sex differences in self-objectification, restrained eating, and math performance. Journal of Personality and Social Psychology, 75(1), 269-284. Harrison, C. (2019). Anti-Diet: Reclaim Your Time, Money, Well-Being, and Happiness Through Intuitive Eating. New York: Little, Brown Spark. Hazzard, V. M., Loth, K. A., Hooper, L., and Becker, C. B. (2020). Food insecurity and eating disorders: a review of emerging evidence. Current Psychiatry Reports, 22(12), 74. Herman, C. P., and Mack, D. (1975). Restrained and unrestrained eating. Journal of Personality, 43(4), 647-660. Keys, A., Brožek, J., Henschel, A., Mickelsen, O., and Taylor, H. L. (1950). The Biology of Human Starvation. Minneapolis: University of Minnesota Press. Linardon, J., Tylka, T. L., and Fuller-Tyszkiewicz, M. (2021). Intuitive eating and its psychological correlates: a meta-analysis. International Journal of Eating Disorders, 54(7), 1073-1098. Mann, T., Tomiyama, A. J., Westling, E., Lew, A.-M., Samuels, B., and Chatman, J. (2007). Medicare's search for effective obesity treatments: diets are not the answer. American Psychologist, 62(3), 220-233. Mountjoy, M., Ackerman, K. E., Bailey, D. M., et al. (2023). 2023 International Olympic Committee's (IOC) consensus statement on Relative Energy Deficiency in Sport (REDs). British Journal of Sports Medicine, 57(17), 1073-1097. Murray, S. B., Nagata, J. M., Griffiths, S., et al. (2017). The enigma of male eating disorders: a critical review and synthesis. Clinical Psychology Review, 57, 1-11. Neumark-Sztainer, D., Wall, M., Guo, J., Story, M., Haines, J., and Eisenberg, M. (2006). Obesity, disordered eating, and eating disorders in a longitudinal study of adolescents: how do dieters fare 5 years later? Journal of the American Dietetic Association, 106(4), 559-568. Nichter, M. (2000). Fat Talk: What Girls and Their Parents Say About Dieting. Cambridge, MA: Harvard University Press. Puhl, R. M., and Heuer, C. A. (2009). The stigma of obesity: a review and update. Obesity, 17(5), 941-964. Stice, E., Marti, C. N., Spoor, S., Presnell, K., and Shaw, H. (2008). Dissonance and healthy weight eating disorder prevention programs: long-term effects from a randomized efficacy trial. Journal of Consulting and Clinical Psychology, 76(2), 329-340. Thai, H., et al. (2023). Reducing social media use improves appearance and weight esteem in youth with emotional distress. Psychology of Popular Media. https://doi.org/10.1037/ppm0000460 Tiggemann, M., and Zaccardo, M. (2015). "Exercise to be fit, not skinny": the effect of fitspiration imagery on women's body image. Body Image, 15, 61-67. Tomiyama, A. J., Carr, D., Granberg, E. M., et al. (2018). How and why weight stigma drives the obesity "epidemic" and harms health. BMC Medicine, 16, 123. Tribole, E., and Resch, E. (2020). Intuitive Eating: A Revolutionary Anti-Diet Approach (4th ed.). New York: St. Martin's Essentials. Tylka, T. L., and Wood-Barcalow, N. L. (2015). What is and what is not positive body image? Conceptual foundations and construct definition. Body Image, 14, 118-129. Vadeboncoeur, C., Townsend, N., and Foster, C. (2015). A meta-analysis of weight gain in first year university students: is freshman 15 a myth? BMC Obesity, 2, 22. Vadeboncoeur, C., Foster, C., and Townsend, N. (2016). Freshman 15 in England: a longitudinal evaluation of first year university student's weight change. BMC Obesity, 3, 45. Zagorsky, J. L., and Smith, P. K. (2011). The Freshman 15: a critical time for obesity intervention or media myth? Social Science Quarterly, 92(5). Further Reading Evelyn Tribole and Elyse Resch, Intuitive Eating (4th edition, St. Martin's Essentials, 2020).** The original and most thorough account of intuitive eating by the two dietitians who developed it. Readers recovering from an eating disorder should use it alongside professional support rather than on its own. Christy Harrison, Anti-Diet (Little, Brown Spark, 2019).** A dietitian and journalist's history and critique of diet culture, including its "wellness" disguises. Useful for understanding how the ideas examined in Chapter 3 developed. Lindsay Kite and Lexie Kite, More Than a Body (Houghton Mifflin Harcourt, 2020).** Two body image researchers on self-objectification and how to build a relationship with the body based on what it does rather than how it looks. Close in spirit to the body-neutral approach of Chapter 5. Sonya Renee Taylor, The Body Is Not an Apology (Berrett-Koehler, 2018; 2nd edition 2021).** A writer and activist connects body shame to broader systems of oppression. A valuable complement to the more personal focus of body neutrality. Carolyn Costin and Gwen Schubert Grabb, 8 Keys to Recovery from an Eating Disorder (W. W. Norton, 2012).** A practical, compassionate guide written by a clinician and a therapist who have both recovered from eating disorders. Suitable for people in recovery and those supporting them. Tracy Tylka and Nichole Wood-Barcalow, "What is and what is not positive body image?" (Body Image, 2015). The academic article behind much of Chapter 5's account of positive body image. Accessible to motivated non-specialists. National Alliance for Eating Disorders (allianceforeatingdisorders.com) and ANAD (anad.org). Two US organisations offering helplines, support groups, treatment directories and information for people with eating disorders and their families. Readers outside the United States should look for their national equivalent, such as Beat in the UK, NEDIC in Canada or the Butterfly Foundation in Australia. Hashtags: #OvercomingBodyImageIssues #BodyImage #BodyImageAwareness #BodyImageAcceptance #BodyNeutrality #BodyPositivity #BodyRespect #BodyAppreciation #BodyFunctionality #BodyConfidence #SelfAcceptance #SelfCompassion #SelfWorth #PositiveBodyImage #BodyDissatisfaction #Freshman15Myth #FreshmanFifteen #DismantlingDietCulture #DietCulture #AntiDietCulture #DietCultureAwareness #DietMyths #WeightNeutralHealth #WeightStigma #WeightInclusivity #BodyDiversity #BodyAutonomy #HealthyRelationshipWithFood #FoodFreedom #FoodNeutrality #FlexibleEating #RegularEating #NutritionAwareness #IntuitiveEating #MindfulSelfCare #StudentWellbeing #CollegeStudentHealth #UniversityWellbeing #CampusMentalHealth #FreshmanYear #CollegeTransition #YoungAdultDevelopment #StudentMentalHealth #MentalHealthAwareness #EatingDisorderAwareness #EatingDisorderPrevention #DisorderedEatingAwareness #EatingDisorderRecovery #EarlyIntervention #MentalHealthSupport #CampusCounseling #SocialComparison #SocialMediaAndBodyImage #DigitalWellbeing #MediaLiteracy #SelfObjectification #BodySurveillance #BodyCheckingAwareness #AppearancePressure #FatTalk #FoodInsecurity #InclusiveWellness #EnjoyableMovement #HealthyCampusCulture #EmotionalWellbeing #PsychologicalWellbeing #EvidenceBasedNutrition #BodyImageEducation #StudentEmpowerment #WellbeingWithoutWeightFocus

Download the Book (PDF): Introduction In the last week of February 2023, Meta released a family of language models called LLaMA to a list of approved researchers. Within about a week the weights were circulating on a public file-sharing link posted to 4chan. Meta had built the models; it no longer controlled them. What happened over the following three months is the clearest demonstration we have of how open artificial intelligence actually works. A programmer in Bulgaria named Georgi Gerganov wrote a few thousand lines of plain C++ that let the smallest LLaMA model run on a MacBook. A team at Stanford spent a few hundred dollars generating 52,000 instruction-following examples from an OpenAI model and used them to turn LLaMA into a passable chatbot they called Alpaca. A group of academics calling itself LMSYS fine-tuned another version on conversations users had shared from ChatGPT and called it Vicuna. Researchers at the University of Washington worked out how to fine-tune a 65-billion-parameter model on a single graphics card by compressing its weights to four bits and training only a sliver of new parameters on top. By May an internal Google memo, leaked under the title "We Have No Moat, and Neither Does OpenAI," was warning colleagues that the open community was "lapping" the large labs on cost and speed of iteration. That memo got one thing right and one thing wrong. It was right that something powerful had been unleashed: once a capable set of weights exists in public, the cost of adapting, compressing, combining, and deploying it collapses toward zero, and thousands of people start doing so in parallel. It was wrong about the moat. Not one of those spring-2023 projects trained a foundation model. Every one of them started from weights that a corporation had paid millions of dollars to produce. The open community had not abolished the most expensive step in building AI. It had made everything after that step cheap. The argument of this book That distinction is the controlling idea of what follows. Open-weight AI democratizes the last mile of the technology — adaptation, compression, evaluation, and deployment — far more completely than it democratizes the first mile of pretraining. The future of the ecosystem depends on whether licenses, policy, and new techniques for distributed training can push that democratization upstream, or whether the community remains permanently downstream of a few organizations that choose, for their own reasons, to give their work away. The two halves of that claim pull in different directions, and both matter. The first half is a story of genuine, measurable empowerment. A graduate student with a gaming GPU can today specialize a model that would have been the most capable system on earth in 2022. A hospital can run a strong model entirely inside its own network, never sending a patient record to a third party. A government can audit what a model does, instead of taking a vendor's word for it. Over two million public models now sit on the Hugging Face Hub, the vast majority of them derivatives: fine-tunes, quantizations, and merges of a few dozen base models. That derivative layer is where the open ecosystem's energy lives. The second half is a story of dependence. The base models those millions of derivatives sit on come from a short list of organizations: Meta, Alibaba, DeepSeek, Google, Mistral, Moonshot, Zhipu, OpenAI on one notable occasion, and a handful of research institutes. Each released its weights for strategic reasons — to commoditize a competitor's product, to win developer mindshare, to attract talent, to serve national industrial policy — and each can stop. Meta, which more than anyone made "open-source AI" a mainstream phrase, launched its first flagship model that was not open-weight in April 2026. The licenses attached to these releases range from genuinely permissive to restrictive in ways most downstream users never read. And the regulations now being written in Brussels, Washington, Sacramento, and Beijing treat openness sometimes as a public good to be protected and sometimes as a risk to be contained. What the reader needs to follow along No technical background is assumed beyond curiosity. A few terms will recur constantly, and it is worth fixing them at the outset. A model in this book means a neural network, usually a transformer, that has been trained to predict text, images, or other data. Its weights (also called parameters) are the billions of numbers learned during training; they are the model in any practical sense. Someone holding the weights and a few hundred lines of code can run the model, modify it, or build on it. Pretraining is the initial, enormously expensive phase in which a model learns from trillions of tokens of text. Fine-tuning or post-training is the much cheaper phase that follows, in which the model is taught to follow instructions, hold a conversation, reason step by step, or specialize in a domain. Inference is simply running the model to get outputs. An open-weight model is one whose weights are downloadable by the public. That is a narrower thing than open-source AI, a phrase the Open Source Initiative has tried, with limited success, to define as requiring not only weights but also the training code and enough information about the training data to reproduce the system. Chapter 1 is about why this distinction matters and why the industry has been content to blur it. How the book is built The chapters move from definitions, through technique, to law, risk, and economics. Chapter 1 asks what "open" means when applied to a system whose most important ingredient, its training data, is almost never released, and lays out the spectrum from closed APIs to fully reproducible research models. Chapter 2 traces how the open ecosystem came to exist, from EleutherAI's volunteer-built models through the LLaMA leak to the arrival of Chinese labs as the dominant source of open weights. Chapters 3 and 4 are the technical heart of the book: Chapter 3 explains parameter-efficient fine-tuning — LoRA, QLoRA, and their relatives — the techniques that made adaptation cheap; Chapter 4 covers quantization, local inference, and model merging, the techniques that made deployment and recombination cheap. Chapter 5 examines the infrastructure that holds the community together: the model hub, the file formats, the leaderboards, and the evaluation problems that come with millions of anonymous contributors. Chapter 6 confronts the first mile directly. It explains why pretraining has resisted decentralization, and how a series of algorithms and collective training runs since 2023 — DiLoCo, DisTrO, INTELLECT-1 and its successors, Nous Research's Psyche network — have begun to chip away at that resistance, and how far they still have to go. Chapter 7 is a close reading of the licenses that govern open weights: Apache and MIT, the Llama Community License, the responsible-AI licenses, the custom terms from Google, Alibaba, and others, and the unsettled question of whether weights can be copyrighted at all. Chapter 8 turns to public law: the EU AI Act's treatment of open-source models, the shifting American position, and the state-level fights in California. Chapter 9 takes the safety objection seriously, asking what the evidence says about the marginal risk of releasing weights and how easily safeguards can be stripped from a downloaded model. Chapter 10 examines the economics of release — why companies give away assets that cost tens of millions of dollars, what DeepSeek's emergence changed, and what "democratizing the frontier" can and cannot mean. The conclusion draws these threads into a judgment about where the ecosystem stands and what its participants — developers, companies, policymakers, and ordinary users — should do about it. A note on currency This field moves faster than almost any other. Specific model names in this book will age quickly; a release that tops a leaderboard one month is often superseded the next. The underlying mechanics change more slowly. Low-rank adaptation was introduced in 2021 and remains the default way to fine-tune. The economics of who can afford pretraining have shifted at the margins but not at the core. The legal questions around licenses and copyright are, if anything, less settled than they were three years ago. The book is written to be useful after the particular models it names have been forgotten, by explaining the forces that will shape whatever replaces them. Chapter 1. What "Open" Means When the Data Stays Closed Open-source software rests on a simple bargain. The source code is the thing a programmer reads, edits, and compiles; publish it under a license that guarantees the freedoms to use, study, modify, and redistribute, and anyone can rebuild the program from scratch and change it at will. The Open Source Definition, maintained by the Open Source Initiative since 1998, turned that bargain into ten criteria, and for a quarter century the criteria worked well enough that "open source" became one of the most valuable labels in technology. Machine learning breaks the bargain in a specific way. A trained model has no single artifact equivalent to source code. It has at least four: the code that defines the network's architecture and runs it; the code that trained it, including data processing pipelines and the many small engineering choices that determine whether a training run succeeds; the training data itself, often trillions of tokens scraped, licensed, filtered, and synthesized; and the weights, the numerical output of running the second on the third. Releasing the weights lets you use and modify the model. It does not let you rebuild it, and it tells you surprisingly little about why it behaves as it does. The four artifacts and what each one buys you Consider what each artifact enables, because the differences explain most of the arguments that follow. Inference code and architecture are nearly always public, and nearly worthless on their own. The transformer architecture has been documented since 2017. A model's specific configuration — the number of layers, the attention variant, the size of its vocabulary, how its mixture-of-experts routing works — is usually described in a technical report and implemented in open libraries within days of release. Knowing the blueprint of a building does not give you the building. Weights are what most people mean by an open model. With weights, you can run the model on your own hardware, which means no per-token fees, no data leaving your premises, no risk that a vendor will deprecate the version your product depends on, and no rate limits. You can fine-tune it, which means teaching it your domain, your style, your task. You can compress it, inspect its internal activations, prune it, merge it with other models, or distill it into a smaller one. Weights convert a model from a service you rent into an asset you own. Nearly every technique in Chapters 3 and 4 depends on having them. Training code lets you reproduce the training process, at least in principle, and learn from the engineering. In practice it matters most to researchers and to anyone attempting to train a competing model. Large labs guard it closely, partly because it encodes hard-won efficiency tricks. DeepSeek's decision in February 2025 to publish several pieces of its training and inference infrastructure — communication libraries for mixture-of-experts models, optimized attention kernels, a parallel file system — was unusual enough to be treated as news. Training data is the artifact almost no one releases, and it is the one that determines most of a model's capabilities, biases, and knowledge. A model's weights are, in a loose but useful sense, a compressed and lossy summary of its training data. Without the data, you cannot audit whether a model was trained on copyrighted books, personal information, or benchmark answers. You cannot study how data composition affects behavior. And you cannot retrain the model with one problematic source removed. The reasons labs withhold data are partly competitive — data curation is now a major source of advantage — and partly legal: publishing a dataset that contains copyrighted material is far riskier than publishing weights trained on it. So the spectrum of openness is really a spectrum of which artifacts are released and under what terms. Table 1 sets out where several prominent releases fall. Table 1. What representative model releases make available. Release Weights Training code Training data License on weights Closed API models (e.g. GPT-5, Claude, Gemini) No No No Terms of service only Llama 3.1 (Meta, 2024) Yes No No; described only in outline Llama 3.1 Community License DeepSeek-R1 (2025) Yes Partial infrastructure code No MIT Qwen3 (Alibaba, 2025) Yes No No Apache 2.0 gpt-oss (OpenAI, 2025) Yes No No Apache 2.0 with usage policy OLMo 2 (Allen Institute for AI, 2024) Yes Yes Yes Apache 2.0 Pythia (EleutherAI, 2023) Yes, with intermediate checkpoints Yes Yes (the Pile) Apache 2.0 The table reveals the basic structure of the ecosystem. The models most people use and build on occupy the middle rows: weights released, often under a permissive license, with training code and data withheld. The fully open rows are dominated by research institutes and nonprofits, and their models, while respectable, have generally trailed the middle-row releases in capability. The fight over a definition In 2023 the Open Source Initiative began a public process to decide what "open source" should mean for AI. It ran for nearly two years, through drafts, town halls, and working groups that tried to determine which components a person actually needs in order to exercise the four software freedoms on an AI system. Version 1.0 of the Open Source AI Definition was released in October 2024. The definition requires three things. The model's parameters must be available under terms that allow use, study, modification, and sharing. The complete source code used to train and run the system must be available under an OSI-approved license. And — the contested part — the developer must provide "data information": a sufficiently detailed description of the training data, including its provenance, scope, characteristics, and how it was obtained and selected, such that "a skilled person" could build a substantially equivalent system. Where training data can legally be shared, the definition expects it to be; where it cannot, as with medical records, a detailed description suffices. That compromise satisfied almost no one completely. One camp argued that without the data itself, a system cannot truly be studied or modified, so the definition was too weak and amounted to openwashing with an official seal. Another camp, including many companies, argued that the training code and data-information requirements were impractical and would leave nearly every useful model outside the definition. Both camps were right about the consequences. By the OSI's standard, Llama does not qualify, because its license restricts use and its training data is not described in the required detail. Neither do most of the Apache-licensed Chinese releases, whose weights are permissively licensed but whose training code and data descriptions fall short. Models such as Pythia, OLMo, and the Swiss Apertus models released in 2025 by EPFL, ETH Zurich, and the Swiss National Supercomputing Centre, which publish their data pipelines and training recipes, are among the few that clearly do. Other frameworks have tried to make the gradations explicit rather than drawing a single line. The Model Openness Framework, published under the Linux Foundation's AI and Data umbrella in 2024, defines three classes of increasing completeness, from releases that include weights and architecture through to those that also include all training data, code, and intermediate checkpoints. Academic researchers at Radboud University and elsewhere have maintained openness rankings that score instruction-tuned models on more than a dozen dimensions — weights, data, code, documentation, peer-reviewed papers, licensing — and have consistently found that the models marketed most loudly as open often score worst on everything except weights. Why the distinction is more than pedantry It is tempting to treat this as a quarrel over branding. It is more than that, for three reasons. The first is that the word "open" carries legal weight. The EU AI Act, discussed in Chapter 8, exempts models released under a "free and open-source licence" that makes their parameters public from several of its obligations. Whether a model with a restrictive acceptable-use policy or a commercial-user threshold counts as free and open-source is a question with compliance costs attached. Regulators have shown signs of reading the term narrowly: the Act's own recitals suggest that a model monetized through the license terms, or that restricts use, may not qualify. The second is that the different artifacts produce different public goods. Weights produce deployment freedom: cheaper, private, customizable inference. Training code and data produce scientific understanding and reproducibility. A world in which weights are abundant but data and recipes are secret is one in which many people can use powerful models but very few can explain them or build alternatives. The research value of Pythia, which released 154 intermediate checkpoints for each of its models along with the exact order in which training data was seen, came precisely from making the training process itself an object of study. Interpretability researchers used those checkpoints to watch capabilities emerge during training; memorization researchers used the known data order to trace which training documents a model could reproduce verbatim. None of that is possible with weights alone. The third reason is dependence. An organization that builds on weights alone has a product that is permanently downstream of the original developer's choices. It cannot fix a flaw that originates in pretraining data. It cannot extend the model's knowledge cutoff except by fine-tuning, which adds facts poorly. It cannot produce the next version. When the developer stops releasing, its downstream users are stuck with whatever they last received. Training code and data are what would let a community continue a model's lineage independently, as software communities routinely fork abandoned projects. Without them, an open-weight model is more like freeware than like Linux: free to use, sometimes free to modify, but not free to regenerate. The weights-are-enough argument The opposing view deserves its strongest statement. Its proponents argue that weights are, for nearly every practical purpose, what users need. Few organizations have the compute to retrain a frontier-scale model even with full data and code in hand; DeepSeek-V3's final training run alone was estimated by its developers at roughly 2.8 million GPU hours. For a hospital, a startup, or a government agency, the freedoms that matter — run it privately, adapt it, inspect its behavior, avoid lock-in — all flow from the weights. Fine-tuning, which Chapter 3 shows has become extraordinarily cheap, is a powerful form of modification. And mechanistic interpretability research, which tries to understand how models compute internally, works on weights and activations, not on training data. There is truth in this. Most of the empowerment the open ecosystem has delivered has come through weights alone, and the derivative economy on Hugging Face — hundreds of thousands of fine-tunes of Llama and Qwen — was built without anyone seeing the underlying data. Insisting that only fully reproducible models deserve the word "open" risks defining the most useful part of the ecosystem out of existence. But the weights-are-enough view concedes the central point of this book. It is an argument that the last mile is what matters, because the first mile is out of reach anyway. That may be a reasonable description of the present. It is a weak foundation for a community that wants to remain independent of the organizations that currently supply its base models. A working vocabulary This book uses three terms, chosen to track the distinctions above rather than any marketing. An open-weight model is one whose weights are publicly downloadable, whatever its license. This is the broadest category and includes Llama, Gemma, Qwen, DeepSeek, Mistral's open releases, and gpt-oss. A permissively licensed model is an open-weight model released under a standard license such as Apache 2.0 or MIT that imposes no field-of-use restrictions and no user thresholds. Many of the most widely used Chinese releases, Mistral's Apache models, gpt-oss, and Google's Gemma 4 fall here. A fully open model is one that releases weights, training code, and training data or detailed data documentation sufficient for reproduction, under open licenses. OLMo, Pythia, Apertus, and a handful of others belong to this group. When the book says "open-source AI" without qualification, it refers loosely to the whole community and its practices, because that is how the phrase is actually used, not to any one of these categories. The distinctions matter because they map onto the book's central argument. Open-weight release has made the last mile accessible. Permissive licensing determines whether that access can be used commercially without asking anyone's permission. Full openness is what it would take for the first mile to follow. The next chapter shows how the ecosystem arrived at a situation in which the first condition is abundantly met, the second increasingly so, and the third only rarely. Chapter 2. How the Open Ecosystem Formed The open-weight ecosystem did not emerge from a single decision. It formed in layers, each laid down by a different kind of actor with a different motive: volunteer researchers who wanted to study models the labs would not share, a corporation that lost control of its weights and then decided to embrace the loss, a French startup that used open release as a market-entry strategy, and Chinese laboratories for whom openness served both commercial and national purposes. Understanding those layers explains why the ecosystem looks the way it does: rich downstream, thin upstream, and dependent on the strategic calculations of a few base-model producers. Before the flood: staged release and the volunteer era For most of the history of deep learning, releasing trained models was normal. Research labs published weights for image classifiers, word embeddings, and, in 2018 and 2019, the first generation of transformer language models. Google released BERT. OpenAI released the first GPT. The norm cracked in February 2019, when OpenAI announced GPT-2, a 1.5-billion-parameter model, and declined to release the full version, citing concerns about misuse for generating disinformation. It instead released progressively larger versions over nine months, an approach it called staged release, publishing the full model in November 2019 after concluding it had seen no strong evidence of misuse. The episode was widely mocked at the time, and in hindsight GPT-2 was harmless. But it established two lasting ideas: that model weights could be treated as potentially hazardous, and that a lab might reasonably keep its best model closed. When OpenAI's GPT-3 arrived in 2020 at 175 billion parameters, it was available only through an API. The response came from volunteers. EleutherAI began in July 2020 as a Discord server whose members wanted to replicate GPT-3 so that researchers outside a few companies could study large language models. They had no funding and no data center. They assembled the Pile, an 825-gigabyte English text dataset drawn from twenty-two sources including academic papers, books, code, and web text, and released it publicly at the end of 2020. Using compute donated through Google's TPU Research Cloud and, later, by the cloud company CoreWeave, they trained and released GPT-Neo in March 2021, GPT-J-6B in June 2021, and GPT-NeoX-20B in February 2022 — at the time the largest publicly available dense language model. In 2023 they released the Pythia suite, sixteen models trained identically on the same data in the same order, specifically designed for scientific study of training dynamics. EleutherAI's models were never competitive with the best closed systems. Their importance was demonstrative. They showed that a loosely organized community with donated compute could produce models that were useful for research and moderately useful in practice, and they established the norm, which persists in the research corner of the ecosystem, of releasing data and code alongside weights. The second volunteer effort was larger and more formal. BigScience, convened by Hugging Face in 2021, brought together more than a thousand researchers from dozens of countries in a year-long workshop modeled loosely on large physics collaborations. Its output, released in July 2022, was BLOOM: a 176-billion-parameter multilingual model trained on the French government's Jean Zay supercomputer, covering 46 natural languages and 13 programming languages. BigScience published its dataset governance process, its data sources, and extensive documentation, and it released BLOOM under a new kind of license, the BigScience RAIL License, which permitted broad use while prohibiting a list of harmful applications. That license became the template for a whole family discussed in Chapter 7. BLOOM was a landmark in collaborative science and a modest success as a model. It was expensive to run, undertrained relative to its size by the standards that emerged soon after, and outperformed within months by models trained with more data. Its legacy is the proof that a public, multinational, transparent pretraining effort at the hundred-billion-parameter scale was possible, and the sobering observation that it required access to a national supercomputer to happen at all. Meanwhile, Meta's research division released OPT-175B in May 2022, a replication of GPT-3 made available to researchers on request under a noncommercial license, with an unusually candid logbook documenting the failures and restarts of its training run. And in August 2022, Stability AI and its collaborators released Stable Diffusion, an image-generation model whose weights anyone could download. Stable Diffusion's release, more than any language model's, previewed what was coming: within weeks, a sprawling community had built user interfaces, fine-tuning tools, and thousands of specialized variants, and the model was running on consumer graphics cards worldwide. The LLaMA moment Then came ChatGPT in November 2022, and with it the realization, inside and outside the industry, that large language models were going to be a mass-market technology. The closed labs pulled further into secrecy. OpenAI's GPT-4 technical report in March 2023 declined to disclose the model's size, architecture, training compute, or data, citing "the competitive landscape and the safety implications." Meta's LLaMA, announced on February 24, 2023, was a set of four models from 7 to 65 billion parameters, trained on more data than was then typical for their size. The key finding of its accompanying paper was that a 13-billion-parameter model trained on a trillion tokens could match the original 175-billion-parameter GPT-3 on many benchmarks. That made LLaMA small enough to run on hardware ordinary researchers could afford. Meta made it available under a noncommercial research license to approved applicants. Within about a week, someone posted a torrent link to the weights on 4chan, and they spread everywhere. The explosion that followed has been described in the introduction: llama.cpp, Alpaca, Vicuna, QLoRA, and hundreds of lesser-known projects. What matters here is the structure it created. For the first time, a near-frontier base model was in the hands of thousands of developers at once, and nearly all of their effort went into the layers above pretraining. Instruction tuning, chat formatting, quantization, local inference, retrieval augmentation, fine-tuning on domain data — each was attacked simultaneously by many independent groups who shared results openly and built on each other within days. The pace was unlike anything the closed labs could match internally, because no single organization could afford to explore so many directions at once. Meta drew the lesson. In July 2023 it released Llama 2, this time deliberately, with weights available for commercial use under a custom license, and with a chat-tuned version included. Llama 2 came with a launch partnership with Microsoft and availability on all major clouds. The license carried two restrictions that would shape the ecosystem's legal culture: an acceptable use policy prohibiting a list of harmful applications, and a clause requiring any company with more than 700 million monthly active users to request a separate license from Meta — a threshold that, in practice, excluded only Meta's largest competitors. Llama 2 instantly became the default base model for the open community. Market entry by torrent: Mistral and the permissive turn In September 2023, a Paris startup founded only months earlier by former Google DeepMind and Meta researchers released its first model by posting a magnet link on the social network then still called Twitter, with no announcement and no blog post. Mistral 7B, released under the Apache 2.0 license, outperformed Llama 2's 13-billion-parameter model on most benchmarks despite being roughly half the size. In December, Mistral did it again with Mixtral 8x7B, a mixture-of-experts model — one that routes each token through only a subset of its parameters — that matched or exceeded Llama 2 70B and GPT-3.5 on many tasks while using only about 13 billion active parameters per token. Mistral's contribution to the ecosystem's structure was twofold. Technically, it popularized mixture-of-experts architectures in the open world, which would become the dominant design for large open models. Legally, it showed that a company could release competitive weights under a standard, unrestricted open-source license and still build a business, by selling larger closed models, enterprise deployments, and services. Apache 2.0 meant no acceptable use policy, no user thresholds, and no need to read a custom document. It set a benchmark against which every custom license would subsequently be compared. The United Arab Emirates' Technology Innovation Institute followed a similar arc with its Falcon models in 2023. Falcon 40B initially shipped under a license requiring royalties above a revenue threshold; within weeks, under community pressure, TII switched it to Apache 2.0. The episode was an early signal that the community would reward permissive terms and resist restrictive ones, at least when good alternatives existed. Meta escalated through 2024. Llama 3 arrived in April; in July, Llama 3.1 included a 405-billion-parameter model that Meta claimed was competitive with the best closed models of the time. Mark Zuckerberg accompanied it with a public letter titled "Open Source AI Is the Path Forward," which compared the situation to the 1990s competition between proprietary Unix and open Linux and argued that open models would ultimately win on cost, customizability, and security. The Llama 3.1 license also, for the first time, explicitly allowed developers to use Llama's outputs to train other models, provided the resulting models carried "Llama" in their names. The center of gravity moves east The Zuckerberg letter marked the high point of American leadership in open weights. Over the following eighteen months, the center of gravity shifted to China. Alibaba's Qwen team had been releasing models since 2023, initially under a custom license with a commercial-user threshold of 100 million monthly active users. With Qwen2 and Qwen2.5 in 2024, it moved most of its models to Apache 2.0 and released them in a range of sizes, from under a billion parameters to 72 billion, with specialized versions for code and mathematics. Qwen models became the preferred base for fine-tuning in much of the community, partly because of their quality at small sizes and partly because of their permissive terms. By early 2026, according to Hugging Face's own analysis of its Hub, the Qwen family had more than 113,000 derivative models — more than Google's and Meta's families combined. DeepSeek, a laboratory funded by the Chinese quantitative hedge fund High-Flyer, released DeepSeek-V3 in December 2024: a 671-billion-parameter mixture-of-experts model with 37 billion active parameters per token, whose technical report put the cost of its final training run at about 5.6 million dollars in rented GPU time. In January 2025, it released DeepSeek-R1, a reasoning model trained with large-scale reinforcement learning that approached the performance of OpenAI's o1 on mathematics and coding benchmarks, under the MIT license. It also released six smaller "distilled" models based on Qwen and Llama, fine-tuned on R1's reasoning traces. On January 27, 2025, as R1's app climbed the download charts, Nvidia's market value fell by roughly 590 billion dollars in a single day, the largest one-day loss for any company in U.S. stock market history. The cost figure was widely misunderstood — it excluded research, failed runs, and the cost of the hardware itself — but the broader point stood: a near-frontier model was available to anyone, under the most permissive license in common use. After R1, Chinese open releases accelerated. Moonshot AI's Kimi K2, released in July 2025, was a trillion-parameter mixture-of-experts model with 32 billion active parameters, under a modified MIT license. Zhipu released its GLM-4.5 series under MIT the same month. Alibaba's Qwen3 family, released in April 2025 under Apache 2.0, spanned dense and mixture-of-experts models with switchable reasoning modes; Qwen 3.5 and 3.6 followed in the first half of 2026. DeepSeek continued with V3.1, V3.2, and preview releases of V4 in April 2026. Hugging Face reported that Chinese models accounted for a plurality of downloads on its Hub over the year to early 2026, and that the most-liked model on the platform had shifted from Meta's Llama to DeepSeek-R1. American and European developers responded in different ways. OpenAI released gpt-oss-120b and gpt-oss-20b in August 2025 under Apache 2.0, its first open-weight language models since GPT-2. Google moved its Gemma family from custom terms to Apache 2.0 with Gemma 4 in 2026. The Allen Institute for AI continued its fully open OLMo line, and Swiss public institutions released Apertus. Meta, after the lukewarm reception of Llama 4 in April 2025 and a costly reorganization that created Meta Superintelligence Labs, launched a closed flagship model, Muse Spark, in April 2026. The structure that resulted Step back from the chronology, and the shape of the ecosystem becomes visible. At the top sits a small number of base-model producers: perhaps a dozen organizations worldwide that release competitive open-weight models trained from scratch. Below them sits an enormous derivative layer of fine-tunes, quantizations, merges, and distillations produced by tens of thousands of individuals, startups, and research groups. Around both sits infrastructure: the Hugging Face Hub, inference engines, training libraries, evaluation suites. Every layer of that structure is open in the sense that matters most to users: anyone can download, run, and modify the models. But the flow of capability runs in one direction. Improvements made in the derivative layer rarely flow back into base models, because the producers do not train on community fine-tunes and the community cannot retrain the bases. When a producer changes strategy, as Meta did, the derivative layer adapts by migrating to a different producer's models, as the community largely migrated from Llama to Qwen. That migration was painless only because another producer happened to be releasing comparable weights under better terms. The volunteer era's dream was a community that could build foundation models itself. What emerged instead was a community extraordinarily good at building on foundation models that others built. The next two chapters explain the techniques that made that downstream layer so powerful; Chapter 6 returns to the question of whether the community can climb back upstream. Chapter 3. The Economics of Adaptation: Parameter-Efficient Fine-Tuning A pretrained language model is a generalist. It has absorbed patterns of grammar, facts about the world, programming idioms, and styles of argument from trillions of tokens, but it does not by default follow instructions, adopt a consistent persona, use a company's terminology, or produce output in a particular format. Getting it to do those things is the job of fine-tuning: continuing training on a smaller, targeted dataset so the model's behavior shifts in the desired direction. Until 2021, fine-tuning meant updating every weight in the model. For a model with billions of parameters, that is expensive in a specific and unforgiving way, and the expense would have confined adaptation to well-funded labs. The techniques collectively called parameter-efficient fine-tuning, or PEFT, broke that constraint. They are the single most important reason the open ecosystem's derivative layer exists, and understanding how they work explains a great deal about what the community can and cannot do. Why full fine-tuning is expensive The cost of training a neural network is dominated less by arithmetic than by memory. To update a weight, a training system must hold the weight itself, the gradient computed for it, and the internal state of the optimizer. The optimizer nearly everyone uses, Adam and its variant AdamW, keeps two running statistics per parameter. In standard mixed-precision training, a common accounting puts the total at roughly 16 bytes per parameter: two bytes for the half-precision weight, two for its gradient, four for a full-precision master copy of the weight, and eight for Adam's two statistics. On top of that comes memory for activations — the intermediate values produced during the forward pass that must be retained for the backward pass — which grows with sequence length and batch size. At 16 bytes per parameter, fully fine-tuning a 7-billion-parameter model requires on the order of 112 gigabytes before activations. A 70-billion-parameter model needs more than a terabyte. The largest consumer graphics cards carry 24 or 32 gigabytes; a data-center accelerator such as Nvidia's H100 carries 80. Full fine-tuning of even a modest open model therefore requires multiple data-center GPUs and the engineering to split the work across them. There is a second cost. Every fully fine-tuned model is a complete copy of the original, at full size. An organization that wants a separate specialized model for each of fifty customers must store and serve fifty full copies. And full fine-tuning on a narrow dataset can degrade the model's general abilities, a phenomenon called catastrophic forgetting. Low-rank adaptation The breakthrough came from a 2021 paper by Edward Hu and colleagues at Microsoft, titled "LoRA: Low-Rank Adaptation of Large Language Models." Its core observation was empirical: when a large pretrained model is fine-tuned, the change to each weight matrix tends to have low "intrinsic rank." In plain terms, the update, though it nominally touches millions of numbers in each matrix, can be closely approximated by a much simpler structure. LoRA exploits this directly. Instead of updating a weight matrix W, which might have dimensions of 4,096 by 4,096 — nearly 17 million numbers — LoRA freezes W and learns two small matrices: one of 4,096 by r, and one of r by 4,096, where r, the rank, is typically between 4 and 64. Their product has the same shape as W and is added to it. With r set to 8, the two small matrices together hold about 65,000 numbers, roughly 0.4 percent of the original. One of the two matrices is initialized to zero, so at the start of training the model behaves exactly like the original, and training gradually learns the adjustment. The consequences cascade. Because the base weights are frozen, they need no gradients and no optimizer state; only the tiny adapter matrices do. The memory required for training collapses toward the memory required just to hold the model. The original paper reported that, applied to GPT-3 with 175 billion parameters, LoRA reduced the number of trainable parameters by a factor of 10,000 and GPU memory requirements by a factor of three, while matching full fine-tuning quality on the benchmarks tested. The output of LoRA training is not a new model but an adapter file, often only tens or hundreds of megabytes. That file can be shared, swapped, and stacked. For deployment, the adapter can be mathematically merged into the base weights, producing a model with exactly the original architecture and no additional inference cost — an advantage over earlier adapter methods, which inserted extra layers that slowed every forward pass. Alternatively, the adapter can be kept separate and loaded on demand, so that a single copy of the base model in memory serves many specialized variants. Systems such as S-LoRA, described by researchers at Berkeley and Stanford in 2023, showed that thousands of adapters could be served concurrently from a single base model on one GPU, swapping them per request. This is the architecture behind many commercial fine-tuning services, and it turned per-customer models from a luxury into a commodity. The community embraced LoRA first in image generation. By early 2023, sites hosting Stable Diffusion LoRAs carried tens of thousands of adapters, each teaching the base model a particular artistic style, character, or visual concept from a few dozen training images, trainable in under an hour on a consumer card. The same pattern reached language models within weeks of the LLaMA leak, when Hugging Face's PEFT library, released in early 2023, made LoRA a few lines of code. QLoRA: fine-tuning on a single card LoRA solved the optimizer-state problem but left the base model itself in memory at 16-bit precision: about 14 gigabytes for a 7-billion-parameter model and 130 for a 65-billion-parameter one. In May 2023, Tim Dettmers and colleagues at the University of Washington published QLoRA, which closed most of the remaining gap. QLoRA stores the frozen base model in 4-bit precision while training LoRA adapters in 16-bit precision on top of it. Three innovations made this work without degrading quality. The first was a new 4-bit data type, NormalFloat4 or NF4, designed around the observation that trained neural network weights are approximately normally distributed; NF4 places its sixteen representable values so that each is equally likely to be used, which is information-theoretically optimal for such data. The second, called double quantization, compressed the small scaling constants that 4-bit quantization requires, saving roughly another third of a bit per parameter. The third used the unified memory feature of Nvidia GPUs to page optimizer states to CPU memory during the brief spikes that would otherwise cause out-of-memory errors. The headline result was that a 65-billion-parameter model could be fine-tuned on a single 48-gigabyte GPU. The team's Guanaco models, trained with QLoRA on a small, high-quality conversation dataset, reached about 99 percent of ChatGPT's performance on the Vicuna benchmark — an evaluation in which GPT-4 judged pairs of responses — after 24 hours of training on one GPU. That benchmark was crude and the comparison flattering, but the order-of-magnitude point was not in doubt. Fine-tuning a model of the class that had been frontier-scale two years earlier now cost about as much as a nice dinner in rented cloud time. The wider family LoRA and QLoRA are the dominant methods, but they belong to a family of approaches that all share the strategy of freezing most of the model and training a small number of new or selected parameters. Table 2 summarizes the main members. Table 2. Principal parameter-efficient fine-tuning methods. Method (year) What is trained Typical trainable share Extra inference cost Main trade-off Adapters (Houlsby et al., 2019) Small bottleneck layers inserted in each block Around 1–4% Yes, extra layers per pass Simple, but adds latency Prefix and prompt tuning (2021) Learned vectors prepended to inputs or attention Well under 1% Slight, longer effective context Weaker on smaller models LoRA (Hu et al., 2021) Low-rank update matrices added to weights Roughly 0.1–1% None once merged Rank limits capacity for very large changes QLoRA (Dettmers et al., 2023) LoRA adapters over a 4-bit frozen base Same as LoRA None once merged Slower training step; quantization nuances DoRA (Liu et al., 2024) LoRA applied to direction, plus a magnitude vector Slightly above LoRA None once merged Closer to full fine-tuning; more compute per step Each variant addresses a specific weakness. Prompt tuning, introduced by Brian Lester and colleagues at Google, learns a set of "soft prompt" vectors that are prepended to the model's input; it is extremely lightweight and showed that, for sufficiently large models, conditioning alone can match fine-tuning, but it underperforms on smaller models of the size the open community typically uses. DoRA, from researchers at Nvidia, decomposes each weight into a magnitude and a direction and applies LoRA only to the direction, which more closely mimics the pattern of updates seen in full fine-tuning. A cluster of further refinements — different initialization schemes, different learning rates for the two LoRA matrices, rank-stabilized scaling — each squeezes out modest gains, and the more practical of them have been folded into standard libraries. How good is cheap? The obvious question is whether parameter-efficient methods are a compromise. The answer turns out to depend on what the fine-tuning is trying to achieve, and the research on it has sharpened considerably since 2023. A 2024 study by Dan Biderman and colleagues, titled "LoRA Learns Less and Forgets Less," compared LoRA and full fine-tuning on continued training in programming and mathematics, where the goal was to add substantial new capability. Full fine-tuning learned more, and the gap was meaningful. But LoRA preserved the model's performance on unrelated tasks far better. The study found that full fine-tuning produced weight changes of much higher rank than typical LoRA configurations could represent — consistent with the idea that adding large amounts of new knowledge requires the full capacity of the network. In 2025, researchers at Thinking Machines Lab published an analysis under the title "LoRA Without Regret" that reached a more favorable conclusion for the post-training settings that matter most in practice. They found that when LoRA is applied to all layers of the model, including the large feed-forward layers that many early configurations skipped, and when learning rates are set appropriately, LoRA matches full fine-tuning on typical instruction-tuning datasets. In reinforcement learning, where each training episode conveys relatively little information, even very low-rank adapters performed as well as full fine-tuning. The capacity of LoRA only became the binding constraint when the dataset was large enough to contain more information than the adapter could store. The practical picture that emerges is coherent. PEFT is excellent at teaching a model new behaviors — following a format, adopting a tone, performing a task, reasoning in a particular style, refusing or not refusing certain requests. It is weaker at teaching a model large quantities of new knowledge, which is better done by full fine-tuning or, more often, by retrieval systems that supply relevant documents at inference time. This maps neatly onto the book's argument. PEFT democratized the adaptation of behavior. The knowledge in a model, laid down in pretraining, remains largely what the original developer put there. The data side of the revolution Cheap training would have mattered much less without cheap data. The second half of the adaptation revolution was the discovery that very small, carefully constructed datasets suffice to reshape a model's behavior. Stanford's Alpaca, released in March 2023, used a method called self-instruct: starting from 175 human-written seed tasks, it prompted OpenAI's text-davinci-003 to generate 52,000 instruction-response pairs, at a reported cost of under 500 dollars, and then fine-tuned LLaMA-7B on them for about 100 dollars of compute. The resulting model was far from ChatGPT, but it followed instructions in a way the base model did not. Two months later, Meta researchers published LIMA ("Less Is More for Alignment"), in which a 65-billion-parameter LLaMA model fine-tuned on just 1,000 carefully curated examples produced responses that human evaluators preferred or rated as equivalent to GPT-4's in a substantial share of cases. LIMA's authors framed this as the "superficial alignment hypothesis": a model's knowledge and capabilities come almost entirely from pretraining, and fine-tuning mostly teaches it which format and style to use when presenting what it already knows. Preference tuning followed the same trajectory toward accessibility. The method OpenAI used to align its chat models, reinforcement learning from human feedback, required training a separate reward model and then running a notoriously unstable reinforcement learning algorithm. In 2023, Rafael Rafailov and colleagues at Stanford introduced Direct Preference Optimization, or DPO, which achieves a similar result by training directly on pairs of preferred and rejected responses with a simple classification-style loss. DPO needed no reward model and no reinforcement learning loop. Within months, Hugging Face's Zephyr-7B used DPO on a dataset of AI-rated preferences to produce a 7-billion-parameter chat model that outperformed Llama 2's 70-billion-parameter chat version on several conversational benchmarks. The Allen Institute's Tülu 3, released in late 2024, published an entire state-of-the-art post-training recipe — data, code, and evaluation — for others to reuse. The same pattern repeated with reasoning in early 2025. Within weeks of DeepSeek-R1's release, which described reinforcement learning with a relatively simple algorithm called GRPO, small groups were reproducing its key behaviors at tiny scale. A Berkeley project called TinyZero reported reproducing R1-style emergent self-verification on simple arithmetic puzzles with a 3-billion-parameter model for under 30 dollars of compute. A Stanford-led team released s1, which fine-tuned a 32-billion-parameter Qwen model on just 1,000 carefully selected reasoning examples and used a simple trick of forcing the model to keep thinking longer, matching OpenAI's o1-preview on some competition mathematics benchmarks. Hugging Face launched Open-R1, an effort to reproduce the full R1 pipeline in public. Much of this data, it should be noted, was generated by other models — often closed models whose terms of service prohibit using their outputs to train competitors. Distillation from stronger models has been one of the open community's most powerful and most legally fraught tools, and it creates its own form of dependence: the derivative layer is downstream not only of open base models but, frequently, of closed teachers. The toolchain What makes all of this usable by non-specialists is a mature toolchain. Hugging Face's Transformers, PEFT, and TRL libraries handle model loading, adapter configuration, and the major training algorithms, including supervised fine-tuning, DPO, and GRPO. Higher-level frameworks such as Axolotl and LLaMA-Factory reduce a fine-tuning run to a configuration file. Unsloth, a small startup's open-source project, rewrote key training kernels to cut memory use and speed up LoRA and QLoRA training substantially on single GPUs, and became a staple of hobbyist and startup fine-tuning. Meta's torchtune and similar projects offer native PyTorch alternatives. The result is that fine-tuning a capable open model on a custom dataset is now within reach of a competent software engineer with a single rented GPU and an afternoon. That is the democratization the open ecosystem has genuinely delivered. It is enormous, and it is bounded: the engineer is reshaping behavior on top of knowledge and capability that someone else, at vastly greater expense, put into the base model. The next chapter turns from training to running models, where the same pattern — dramatic cost collapse downstream of an expensive upstream asset — repeats. Chapter 4. Running and Recombining: Quantization, Local Inference, and Model Merging Fine-tuning changes what a model does. A separate set of techniques changes where and how cheaply it can run, and a third, stranger set lets people combine existing models into new ones without any training at all. Together they complete the picture of the last mile. Quantization and efficient inference engines put capable models on laptops, phones, and single servers. Model merging turned the derivative layer from a collection of isolated fine-tunes into a combinatorial space that anyone could explore. Both developed almost entirely in the open, and both illustrate how a large community working in parallel can extract value from fixed upstream assets far faster than any single organization. The memory wall and the case for fewer bits Running a language model is dominated by a single bottleneck. To generate each token, the model must read essentially all of its active weights from memory and multiply them against the current state. For a model generating one token at a time for one user, the arithmetic is trivial for modern hardware; the limiting factor is how fast weights can be moved from memory to the processor. A useful rule of thumb follows: the maximum generation speed for a single user is roughly the memory bandwidth of the device divided by the size of the model in bytes. A 70-billion-parameter model stored at 16 bits occupies about 140 gigabytes. On a device with 400 gigabytes per second of memory bandwidth, it could generate at most about three tokens per second, assuming it fit in memory at all, which on almost any consumer device it would not. Quantization attacks both problems at once. It stores each weight in fewer bits — 8, 4, or even fewer instead of 16 — reducing both the memory footprint and the bytes that must be moved per token. The same 70-billion-parameter model at about 4.5 bits per weight occupies roughly 40 gigabytes. It now fits on a pair of 24-gigabyte consumer graphics cards or a desktop computer with 64 gigabytes of unified memory, and its maximum generation speed on the same 400-gigabyte-per-second device rises to about ten tokens per second, comfortably faster than most people read. The difficulty is that naive rounding to fewer bits damages a model. Neural network weights are not uniform; some matter far more than others, and a small number of extreme values can dominate a layer's behavior. In 2022, Tim Dettmers and colleagues, in work released as LLM.int8(), showed that large transformers develop "outlier features" — a handful of dimensions with very large magnitudes — that break simple 8-bit quantization once models pass a few billion parameters. Their solution was to keep those outlier dimensions in 16-bit precision while quantizing everything else. That insight, that quantization must protect the parts of a model that matter, runs through every successful method since. A short history of getting below eight bits The first widely used 4-bit method for large language models was GPTQ, published by Elias Frantar and colleagues at the Institute of Science and Technology Austria in late 2022. GPTQ quantizes a model one layer at a time, using a small calibration dataset to measure how each rounding decision affects the layer's output, and adjusting the remaining unquantized weights to compensate for errors as it goes. It could quantize a 175-billion-parameter model to 3 or 4 bits in a few GPU hours with modest quality loss. Activation-aware Weight Quantization, or AWQ, from Ji Lin, Song Han, and colleagues at MIT in 2023, took a different route: it observed that a small fraction of weights, identifiable by the size of the activations flowing through them, are disproportionately important, and scaled those channels to protect them before quantizing. AWQ won a best paper award at the MLSys conference in 2024 and became a standard format for GPU serving. The format that reached the most people, however, came from outside academia. Georgi Gerganov had written a small machine-learning library in C called GGML. In March 2023, days after the LLaMA weights leaked, he released llama.cpp, a dependency-free implementation of LLaMA inference that ran on ordinary CPUs and, soon, on Apple Silicon GPUs. Its community developed a succession of quantization schemes and, in August 2023, a new file format called GGUF that packaged a model's weights, tokenizer, and metadata into a single portable file. GGUF's "k-quant" schemes allocate bits unevenly, giving more precision to the layers and tensors most sensitive to error, so a file labeled with an average of 4.5 bits per weight might hold some tensors at 6 bits and others at 3. Community members, most prolifically a small number of tireless individuals, began publishing GGUF conversions of every notable model within hours of release, in a ladder of sizes from 2 bits to 8. Table 3 places the main formats side by side. Table 3. Common quantization formats and where they are used. Format Typical precision Main runtimes Typical hardware Distinguishing feature GGUF (llama.cpp) 2–8 bits, mixed per tensor llama.cpp, Ollama, LM Studio CPUs, Apple Silicon, consumer GPUs Single portable file; runs almost anywhere GPTQ 3–4 bits vLLM, Transformers, ExLlama Nvidia and AMD GPUs Error-compensating, calibration-based AWQ 4 bits vLLM, SGLang, TGI Data-center and consumer GPUs Protects activation-salient channels bitsandbytes NF4 4 bits Transformers, PEFT (QLoRA) Nvidia GPUs No calibration; standard for QLoRA training FP8 and MXFP4 8 and roughly 4 bits vLLM, SGLang, TensorRT-LLM Recent data-center GPUs Native hardware support; used by developers at release How much quality is lost? The honest answer is that it depends on the model, the method, and the task, and that headline benchmarks often understate degradation on demanding tasks such as long-form reasoning and code. As a broad pattern, 8-bit quantization is close to lossless for most purposes; well-implemented 4- to 5-bit quantization loses a small amount that most users do not notice in conversation; and quality falls off more steeply below about 3 bits. Larger models tolerate aggressive quantization better than smaller ones, which produces a useful rule of thumb that the community discovered empirically: for a fixed memory budget, a larger model quantized to 4 bits usually beats a smaller model at 8 or 16. Developers meet the community halfway The most telling development of 2024 and 2025 was that base-model producers began to design for quantization rather than leaving it to the community. DeepSeek-V3 was trained substantially in 8-bit floating point, an engineering feat that reduced training cost and meant its released weights were natively FP8. Google released "quantization-aware trained" versions of Gemma 3 in 2025, in which the model was fine-tuned while simulating 4-bit precision so that the final quantized weights lost much less quality than post-hoc quantization would. OpenAI shipped gpt-oss with its mixture-of-experts weights already in MXFP4, a 4-bit microscaling format standardized by an industry consortium, allowing the 120-billion-parameter version to run on a single 80-gigabyte GPU and the 20-billion-parameter version on machines with 16 gigabytes of memory. Microsoft researchers pursued the logical extreme with BitNet b1.58, an architecture whose weights take only three values — negative one, zero, and one — trained that way from the start, and released a 2-billion-parameter BitNet model in 2025. This convergence matters for the book's argument. Quantization began as a community hack applied after the fact to weights that labs had designed for data-center hardware. It became a design target for the labs themselves, because local and low-cost deployment had become one of the main reasons anyone chose open weights at all. The local inference stack Around the formats grew a layered software ecosystem. At the bottom sit inference engines. llama.cpp remains the reference for running on CPUs, Apple hardware, and modest GPUs. Apple's MLX framework, released in late 2023, offered an alternative optimized for the unified memory architecture of its chips, where CPU and GPU share a single pool of memory that, on high-end machines, now reaches hundreds of gigabytes — enough to hold models that would require several data-center GPUs elsewhere. For serving many users at once, vLLM, introduced in 2023 by researchers at Berkeley, became the dominant open engine. Its key idea, PagedAttention, manages the memory used to store each conversation's attention state the way an operating system manages virtual memory, in small non-contiguous pages, eliminating the waste that had previously limited how many requests a GPU could handle at once; its authors reported throughput gains of up to 24 times over the Hugging Face Transformers baseline. SGLang, Hugging Face's Text Generation Inference, and Nvidia's TensorRT-LLM occupy similar territory. Above the engines sit tools that make local models accessible to non-specialists. Ollama, which wraps llama.cpp behind a simple command-line interface and a local server compatible with common API formats, made downloading and running a model a one-line operation. LM Studio and similar desktop applications offer graphical interfaces. Because many of these tools expose an interface mimicking OpenAI's API, applications written for a closed model can often be pointed at a local open model by changing a single address. Mixture-of-experts architectures interact with this stack in a way worth understanding. In an MoE model, the total parameter count determines how much memory is needed, but only the active parameters for each token determine how many bytes must be read per token. A model with 30 billion total and 3 billion active parameters needs the memory of a 30-billion-parameter model but can generate at roughly the speed of a 3-billion-parameter one. This makes MoE models particularly well suited to machines with abundant but relatively slow memory, such as Apple's high-memory desktops or servers with large amounts of system RAM. Some of the most popular local models of 2025 and 2026, including several Qwen releases, were MoE designs of exactly this shape. What does local inference buy? For individuals, privacy and independence: conversations that never leave the machine, no subscription, no risk of a provider changing or removing the model. For organizations, the same plus regulatory compliance, predictable costs at scale, and the ability to run in air-gapped environments. For developers in countries or institutions with limited access to American cloud services, it can be the difference between using modern AI and not. The cost is that the best local models remain behind the best hosted ones, and that running large models well still requires hardware costing thousands of dollars. Model merging: training-free recombination The strangest technique in the open toolkit is model merging: combining the weights of two or more models into one, by arithmetic, without further training. That this works at all is surprising. That it worked well enough to dominate public leaderboards for a period in 2024 says something about both the technique and the leaderboards. The theoretical footing comes from a property sometimes called linear mode connectivity. When several models are fine-tuned from the same pretrained base, they tend to end up in the same broad region of the space of possible weights, connected by paths along which performance stays high. Averaging their weights, rather than producing nonsense, often produces a model that retains much of what each learned. In 2022, Mitchell Wortsman and colleagues showed that averaging the weights of multiple fine-tuned image models, a "model soup," improved accuracy over the best individual model. The same year, Gabriel Ilharco and colleagues introduced "task arithmetic": subtracting the base weights from a fine-tuned model's weights yields a "task vector," and task vectors can be added together to combine skills, or subtracted to remove a behavior. Simple addition runs into interference: two task vectors may push the same parameter in opposite directions, or both may contain many small, noisy changes that add up to damage. Two methods published in 2023 addressed this. TIES-Merging, from Prateek Yadav and colleagues, trims each task vector to its largest changes, resolves sign conflicts by majority vote for each parameter, and merges only the agreeing values. DARE, from Le Yu and colleagues, showed that one can randomly drop the large majority of a fine-tune's parameter changes — often 90 percent or more — and rescale the remainder with little loss, then merge the sparse results with far less interference. Spherical linear interpolation, borrowed from computer graphics, became a popular way to blend two models smoothly. The open-source mergekit toolkit, written by Charles Goddard and later maintained by the company Arcee, put all of these methods behind a configuration file that runs on a CPU in minutes. Merging required no GPU, no training data, and no machine-learning expertise beyond choosing which models to combine and in what proportions. The community responded predictably. By early 2024, merged models occupied most of the top positions on Hugging Face's Open LLM Leaderboard, many of them merges of merges with lineages a dozen generations deep. Some merges went beyond averaging. "Frankenmerges" stacked layers from different models to create larger ones: Goliath-120B, assembled by interleaving layers from two fine-tuned Llama 2 70B models, attracted a devoted following despite its improvised construction. The Korean company Upstage formalized a version of this idea, "depth up-scaling," in its SOLAR 10.7B model, which duplicated and stacked layers of a smaller model and then continued pretraining it, producing a model that briefly topped the leaderboard. In March 2024, the Tokyo startup Sakana AI published an "evolutionary model merge" method that used evolutionary search to discover merge recipes automatically, and used it to combine a Japanese language model with English mathematical reasoning models into a Japanese model that was strong at mathematics — a capability none of its parents had in combination. What merging reveals Merging illuminates the structure of the open ecosystem in two ways. First, it shows how much latent value sits in the derivative layer. Thousands of fine-tunes, each representing someone's data and compute, can be recombined at nearly zero marginal cost. The space of possible combinations is vast, and a community can search it far faster than any single lab. When it works, merging is the purest form of last-mile democratization: no compute, no data, only curation and arithmetic. Second, merging exposed the limits of public evaluation. Because merging is cheap and leaderboards rewarded benchmark scores, the community ran what amounted to a massive optimization process against the benchmarks themselves. Many top-ranked merges incorporated fine-tunes trained, deliberately or not, on data overlapping with benchmark questions, and merging could concentrate that contamination. Models that ranked highly often disappointed in real use. Merging also only works within a family: models must share a base architecture and, in practice, a common pretrained ancestor. It recombines what the upstream producers created; it cannot create a new base. The next chapter turns to the infrastructure — hubs, formats, and leaderboards — that made this kind of massive, parallel recombination possible, and to the evaluation problems it created. Chapter 5. The Commons and Its Plumbing: Hubs, Datasets, and the Evaluation Problem An open-source software community needs more than code. It needs places to host projects, conventions for packaging them, ways to find what is good, and norms for documenting what things do. Linux had mailing lists, package managers, and distributions; the web had GitHub. The open AI ecosystem built its own equivalents remarkably fast, and their design shapes what the community can do as surely as LoRA or quantization does. This chapter examines four pieces of that plumbing: the model hub, the open datasets that feed pretraining, the file formats and security practices that make sharing safe, and the evaluation systems the community uses to decide what is worth using. The last turns out to be the weakest, and its weakness reveals something important about a decentralized ecosystem. The hub Hugging Face began in 2016 as a chatbot app for teenagers. Its pivot came in 2018 and 2019, when it released an open-source library, eventually named Transformers, that offered a common interface for loading and running the proliferating family of pretrained language models. The library made it possible to switch from one model to another by changing a single string, and that string pointed to a model repository hosted by Hugging Face. The Hub, as the hosting service came to be known, grew from a convenience into the ecosystem's central registry. Its scale today is difficult to overstate and easy to misread. According to Hugging Face's own report in early 2026, the Hub passed 13 million users in 2025 and hosted more than two million public models and over half a million public datasets, both roughly doubling during the year. But the distribution is extraordinarily skewed. About half of all models had fewer than 200 downloads in total. The top 200 models — one hundredth of one percent of the total — accounted for nearly half of all downloads. The Hub is less a library of two million useful models than a long tail of experiments, personal projects, and automated conversions attached to a short head of widely used bases and their most popular derivatives. That structure is the derivative economy in miniature. Each repository records its base model, so the Hub can display family trees: a base model, its fine-tunes, their quantizations, and merges that combine several branches. Hugging Face's analysis found that Alibaba's Qwen family alone had more than 113,000 derivative models, and over 200,000 when including all repositories tagged with the Qwen name. It also documented a shift in who produces the work. Industry's share of development on the Hub fell from around 70 percent before 2022 to around 37 percent in 2025, while independent and unaffiliated developers rose to account for 39 percent of downloads. The base models still come from companies; an increasing share of what people actually download is made by individuals building on them. The Hub's conventions matter as much as its scale. Each repository carries a model card, a document format proposed by Margaret Mitchell and colleagues in a 2019 paper, which is supposed to describe a model's intended uses, training data, evaluation results, and limitations. In practice, model cards range from rigorous documentation to a single line of text. Repositories carry license metadata, which makes it possible to filter by license, though the metadata is self-reported and often wrong for derivatives. Gated repositories allow a developer to require users to accept terms or provide contact information before downloading; Meta and Google have used gating to collect acceptance of their license terms. The Hub also functions as a de facto governance layer, with real power over what circulates. In 2022, after a researcher fine-tuned GPT-J on posts from 4chan's politics board and released the result as GPT-4chan, Hugging Face restricted access to the model. The company maintains content policies and removes models it judges to violate them, and it has worked with researchers on gating models with potential for misuse. Because no comparably convenient alternative exists, these decisions carry weight. The open ecosystem's central registry is a private company, venture-funded and governed by its own policies, not a public institution or a foundation. The open data layer If weights are the ecosystem's currency, data is its mint, and the data layer is where efforts to push openness upstream have made the most concrete progress. Almost every large language model's pretraining data begins with Common Crawl, a nonprofit that has been archiving the public web since 2008 and makes petabytes of raw pages freely available. Raw Common Crawl is mostly unusable: boilerplate, spam, duplicated pages, machine-generated text, and pages in hundreds of languages. The value lies in filtering and processing it, and for years that processing was a closely held capability of large labs. A series of open datasets has steadily eroded that advantage. EleutherAI's Pile in 2020 was the first widely used open pretraining corpus. In 2023, Together AI released RedPajama, an attempt to reproduce the data recipe described in the LLaMA paper, and later a much larger second version. The Allen Institute released Dolma, a three-trillion-token corpus used to train OLMo, with its full processing toolkit. In 2024, Hugging Face released FineWeb, a 15-trillion-token dataset derived from 96 Common Crawl snapshots, along with detailed ablation studies showing which filtering and deduplication choices improved downstream model quality; its educational subset, FineWeb-Edu, filtered with a classifier trained to identify instructional content, produced notably better models on knowledge and reasoning benchmarks for the same compute. The BigCode project, a collaboration led by Hugging Face and ServiceNow, released The Stack, a large dataset of permissively licensed source code, with a mechanism for developers to check whether their code was included and opt out, and used it to train the StarCoder models. Pleias, a French startup, assembled Common Corpus, roughly two trillion tokens drawn exclusively from public-domain and openly licensed sources, as a demonstration that substantial pretraining data could be assembled without relying on copyrighted text. These datasets are among the most important public goods the open community has produced, and they directly address the gap Chapter 1 identified. With FineWeb and a training framework, a well-funded academic lab can now train a respectable small model with a fully documented recipe. What the open datasets cannot do is close the gap in scale and curation with the frontier labs, whose data now includes licensed content, large volumes of synthetic data produced by their own stronger models, and human-written data purchased at great expense for post-training. The open data layer has made the first mile reproducible at small scale; it has not made it competitive at the frontier. Formats, provenance, and the supply chain Sharing model files at scale created a security problem the community was slow to recognize. For years, the standard format for saving PyTorch models used Python's pickle serialization, which can execute arbitrary code when a file is loaded. Downloading a model from a stranger and loading it was, in principle, equivalent to running a stranger's program. Researchers at the security firm JFrog reported in 2024 that they had found around a hundred models on the Hub containing malicious payloads, some capable of opening a remote connection to the attacker's machine. Later research showed that attackers could craft files that evaded Hugging Face's automated pickle scanning. The community's answer was safetensors, a format developed by Hugging Face that stores only tensor data and metadata, with no capacity for code execution, and that also loads faster. After an independent security audit commissioned in 2023, safetensors became the default format for new models in the Transformers library, and most major releases now ship in it. GGUF, the llama.cpp format, is similarly a pure data format. These choices quietly made the ecosystem much safer. Provenance is a harder problem. A model card claims a model was fine-tuned from a particular base on particular data, but nothing verifies the claim. A repository named to resemble a popular model may contain something else entirely. A fine-tune may have been trained on benchmark answers, copyrighted material, or data designed to implant a hidden behavior. Research on "sleeper agents" and data poisoning has shown that models can be trained to behave normally until triggered by a particular input, and that such behaviors can survive standard safety fine-tuning. For most users, downloading a model from the long tail of the Hub involves trusting an anonymous stranger's description of what they did. The organizations that deploy open models in sensitive settings increasingly restrict themselves to official releases from known developers and conversions from a few trusted community members, which reconcentrates trust in the short head of the distribution. Hosted open models A further piece of infrastructure blurs the line between open and closed. Many people who use open models never download them. Inference providers such as Together AI, Fireworks, Groq, DeepInfra, and the major clouds host popular open-weight models behind APIs, competing on price and speed. Routing services such as OpenRouter let developers switch among dozens of providers serving the same model. This layer has driven the price of running open models toward the cost of the underlying hardware, and it has made open weights relevant to developers who have no interest in managing GPUs. It also changes what openness means in practice. A developer calling DeepSeek-R1 through a third-party API has the same relationship to the model as a developer calling a closed model: a service rented from a provider. The difference is that the market for that service is competitive. If one provider raises prices, degrades quality, or shuts down, others serve the same weights. Open weights, in this mode, function less as a guarantee of local control than as a guarantee of a competitive market for inference. That is a significant benefit, and it is one reason enterprises that never intend to self-host still care whether a model is open. The evaluation problem The hardest problem for a decentralized ecosystem is deciding what is good. A closed lab evaluates its own models internally, with private test sets and expert reviewers. A community of thousands of independent producers needs public, shared evaluation, and public evaluation in machine learning has a structural flaw: any benchmark that becomes a target for optimization ceases to measure what it was designed to measure. The Hugging Face Open LLM Leaderboard, launched in 2023, ran a standard set of benchmarks automatically on any submitted model and ranked the results. It became, for a time, the primary way the community decided which models mattered. It also became the target of exactly the optimization process described in the previous chapter. Fine-tunes trained on data that overlapped with benchmark questions, whether deliberately or through careless use of scraped datasets, rose to the top; merges concentrated their gains; and the leaderboard's top ranks filled with models whose real-world quality did not match their scores. In mid-2024 Hugging Face relaunched the leaderboard with harder, less saturated benchmarks — including MMLU-Pro, GPQA, and a set of competition mathematics problems — partly to reset the contamination. In 2025 it retired the leaderboard altogether, noting that the ecosystem's needs had changed. The most influential alternative was human preference voting. Chatbot Arena, launched by the LMSYS group at Berkeley in 2023, presented users with responses from two anonymous models to the same prompt and asked which was better, aggregating millions of votes into Elo-style ratings. Because the prompts came from real users and the answers were judged by humans, the Arena was harder to game with contaminated data. It became the most cited ranking in the industry and, as LMArena, spun out as a company in 2025. But preference voting has its own distortions. Voters reward length, confident tone, formatting, and agreeable responses, not necessarily accuracy. And large developers gained an advantage that open producers lacked. A 2025 paper by researchers at Cohere and several universities, "The Leaderboard Illusion," documented that some large providers had been able to test many private model variants on the Arena before publicly releasing only the best-scoring one, and that proprietary models received a disproportionate share of the battles that generate training-relevant data. The controversy around Meta's Llama 4 release in April 2025 sharpened the point: the version of Llama 4 Maverick that ranked near the top of the Arena at launch was, as Meta's own announcement disclosed in small print, an experimental variant optimized for conversation, not the model it released for download. When the released version was evaluated, it ranked substantially lower. The open community has developed partial remedies. EleutherAI's Language Model Evaluation Harness provides a shared, reproducible framework for running hundreds of benchmarks, so results can at least be compared consistently. Stanford's HELM project evaluates models across many scenarios and metrics simultaneously. Independent evaluators such as Artificial Analysis run their own standardized tests on both open and closed models. Newer benchmarks hold back private test sets, refresh their questions regularly, or draw problems from sources published after a model's training cutoff, such as recent programming contests, to limit contamination. And forums such as Reddit's r/LocalLLaMA, created in the weeks after the LLaMA leak, serve as a rough but useful clearinghouse for practitioners' impressions. None of this fully solves the problem, and it may be unsolvable in a decentralized setting. The fundamental tension is that open evaluation requires public test data, and public test data leaks into training. The result is that much of the community's quality signal comes from reputation: users trust models from developers with track records and treat the long tail with skepticism. Again, the effect is to reconcentrate attention on the short head — the base-model producers — even in an ecosystem nominally open to anyone. Infrastructure as destiny The plumbing of the open ecosystem was built quickly, mostly by a handful of organizations, and largely as a public good. It works astonishingly well for the last mile: anyone can publish a model, find thousands of others, download them safely in a standard format, run them through standard tools, and compare them on standard benchmarks. Its weaknesses all point in the same direction. Trust, quality signals, and curation flow back toward a small number of known producers. The data layer has made upstream work reproducible but not competitive. And the central registry is itself a private company. If the open ecosystem is to become more than a derivative economy built on donated bases, it needs a way to produce the bases themselves. The next chapter examines the most ambitious attempt to do so. Chapter 6. Climbing Upstream: Decentralized Collective Training Everything described so far happens downstream of pretraining. The community adapts, compresses, merges, and evaluates models that someone else trained. The obvious question is whether the community could train them itself — not a 1-billion-parameter research model on a donated cluster, but a competitive base model, pooled from many independent contributors, owned by no one in particular. Volunteer computing has precedent. SETI@home harnessed millions of home computers to search radio telescope data; Folding@home briefly became the world's most powerful computing system during the COVID-19 pandemic. Why not do the same for AI? For years, the answer was that training a neural network is a fundamentally different kind of computation, and the difference is all about communication. Since late 2023, a series of algorithmic advances and increasingly ambitious collective training runs have shown that the difference can be narrowed far more than most experts believed. Whether it can be narrowed enough to matter at the frontier is the most important open technical question for the future of open AI. Why training resists distribution Searching radio signals is what computer scientists call embarrassingly parallel: each work unit is independent, and a home computer can process its chunk for hours before reporting a tiny result. Training a neural network is the opposite. In the standard approach, data parallelism, many accelerators each hold a copy of the model and process different slices of data. After every training step — typically every second or few — they must average their gradients, so that every copy applies the same update and stays in sync. The gradient is the same size as the model. For a 10-billion-parameter model in 16-bit precision, that is 20 gigabytes, exchanged among all participants at every step. Inside a modern data center, this is feasible because of extraordinary interconnects. GPUs within a server communicate over links measured in hundreds of gigabytes per second; servers connect to one another over networks carrying hundreds of gigabits per second per accelerator. A typical home broadband connection uploads at somewhere between ten megabits and one gigabit per second — a thousand to a hundred thousand times slower. At 100 megabits per second, sending a single 20-gigabyte gradient would take over half an hour. Training would spend almost all of its time waiting. Larger models make it worse. Models too big for one accelerator must be split across many, using pipeline or tensor parallelism, which require even more frequent and latency-sensitive communication. And the internet introduces problems that data centers engineer away: participants join and leave unpredictably, connections vary wildly in speed, and some participants may be malicious, submitting corrupted updates to sabotage or backdoor the model. The early experiments The first serious attempts came from researchers associated with Yandex, Hugging Face, and the University of Washington, working on a library called Hivemind. In 2021 they described "Distributed Deep Learning in Open Collaborations," or DeDLOC, and demonstrated it by training sahajBERT, a Bengali language model, with compute contributed by a few dozen volunteers from the Bengali-speaking community. The model was small and the achievement modest, but it established that a community could pool heterogeneous hardware over the internet to train something useful in a language that large labs had neglected. A later paper introduced SWARM parallelism, which tolerated unreliable and heterogeneous participants by dynamically routing work around slow or failed nodes. The same group built Petals, released in 2022, which applied the idea to running and fine-tuning large models rather than pretraining them. Petals split the 176-billion-parameter BLOOM model across volunteers' GPUs, each holding a few layers, so that users could run the full model collaboratively in the manner of BitTorrent. It worked, slowly, and showed that the internet could host a model too large for any single participant. But it served an existing model; it did not create one. Communicating less: DiLoCo and its descendants The conceptual breakthrough came from Google DeepMind. In November 2023, Arthur Douillard and colleagues published DiLoCo, short for Distributed Low-Communication training. Its insight was to stop synchronizing at every step. In DiLoCo, each worker — which might itself be a cluster of well-connected GPUs — trains its own copy of the model independently for many steps, using a standard optimizer. Every few hundred steps, the workers compute how far their weights have moved from the last synchronized version, a quantity called a pseudo-gradient, and average those. A second, "outer" optimizer applies the averaged pseudo-gradient to produce a new shared model, and the cycle repeats. The idea builds on an older technique known as federated averaging, but DiLoCo's specific choices — particularly using Nesterov momentum in the outer optimizer and the AdamW optimizer for inner steps — made it work at the scale of language models. In the original paper, eight workers synchronizing every 500 steps matched the performance of fully synchronous training while communicating 500 times less. Later work from DeepMind extended the approach, including a "streaming" variant that synchronized different parts of the model at different times to spread out bandwidth demand. Nous Research, an independent lab known for its Hermes fine-tunes, took a different route to the same goal. In 2024 it announced DisTrO, a family of optimizers that compress the information exchanged between workers by orders of magnitude, and published the underlying method, Decoupled Momentum Optimization or DeMo, with co-author Diederik Kingma, one of the inventors of the Adam optimizer. DeMo exploits the observation that the useful signal in optimizer momentum is concentrated in a small number of components; each worker transforms its momentum using a discrete cosine transform, a technique familiar from image compression, and shares only the largest components, letting the rest accumulate locally. In December 2024, Nous used the method to pretrain a 15-billion-parameter model over the internet. Further refinements combined the two families: infrequent synchronization as in DiLoCo, plus aggressive compression of what is sent. Research groups showed that pseudo-gradients can be sparsified, keeping only a small fraction of their largest values, and quantized to a couple of bits each, with error feedback carrying forward what was dropped so it is not lost. The compression ratios compound. A 2026 paper describing one such method, SparseLoCo, reported communication more than 146 times smaller than dense pseudo-gradients, on top of the savings from synchronizing only every thirty steps. The collective runs Algorithms became experiments, and experiments became public campaigns. Table 4 summarizes the most significant collective pretraining and post-training runs to date. Table 4. Notable decentralized training runs. Run (organizer) Year Model size Training data Method Participation sahajBERT (Hivemind collaboration) 2021 Small ALBERT-style model Bengali text DeDLOC Volunteers' heterogeneous hardware INTELLECT-1 (Prime Intellect) 2024 10B dense 1T tokens DiLoCo-based Whitelisted contributors, up to 112 H100s INTELLECT-2 (Prime Intellect) 2025 32B, reinforcement learning on an existing base RL on maths and code tasks Asynchronous RL Permissionless contributors Consilience (Nous Research, Psyche) 2025 onward 40B dense 20T tokens planned DeMo / DisTrO Approved contributors, coordinated on Solana Covenant-72B (Covenant AI with Mila) 2026 72B dense About 1.1T tokens SparseLoCo Permissionless peers via Bittensor Prime Intellect, a San Francisco startup, released OpenDiLoCo, an open implementation of DeepMind's method, in mid-2024, and used an extended version to train INTELLECT-1, a 10-billion-parameter model, on one trillion tokens. Released in November 2024, it was trained across five countries and three continents, with compute contributed by organizations and individuals who had been approved to participate. The run reported 83 percent compute utilization across the globe and 96 percent when nodes were confined to the United States — meaning most of the time was spent computing rather than waiting on the network. As a model, INTELLECT-1 was unremarkable, roughly comparable to centralized models of a couple of years earlier trained on similar amounts of data. As a demonstration, it was the first time a 10-billion-parameter model had been pretrained this way. Prime Intellect's next step changed the task. INTELLECT-2, released in May 2025, was a 32-billion-parameter model trained with reinforcement learning over the internet by permissionless contributors — anyone could join. Reinforcement learning turns out to be naturally suited to decentralization. Most of its compute goes into generating sample answers, or rollouts, which any participant can produce independently using a copy of the current model; only the comparatively infrequent weight updates need careful coordination. Prime Intellect built a verification system, TOPLOC, to check cheaply that contributors had actually run the model they claimed rather than submitting fabricated rollouts. INTELLECT-2 started from an existing Qwen-based reasoning model, so it was decentralized post-training rather than pretraining. Its successor, INTELLECT-3, released in November 2025, was a reinforcement learning post-train of Zhipu's GLM-4.5-Air base model that, according to reporting on the release, ran on a centralized cluster of 512 H200 GPUs — a candid acknowledgment that, for the moment, the most competitive results still came from conventional infrastructure. Nous Research launched its Psyche network in May 2025, with a coordinator running as a smart contract on the Solana blockchain to track participants and training state, and announced its first run, Consilience: a 40-billion-parameter dense model, using the multi-head latent attention architecture popularized by DeepSeek, to be trained on 20 trillion tokens. That is a frontier-class token budget, and it made Consilience the most ambitious collective pretraining effort yet announced. It also made the run long. A comparison published in early 2026 listed Consilience as having processed about 1.2 trillion tokens at the time, with benchmark scores still near those of an untrained model on knowledge tests — unsurprising for a large model early in a very long training schedule, but a reminder that announced targets and delivered models are different things. The most capable collectively pretrained model to date, as of this writing, is Covenant-72B, described in a March 2026 paper by Covenant AI and researchers at Mila, the Quebec AI institute. It was trained on about 1.1 trillion tokens by permissionless peers coordinated through Bittensor, a blockchain network that pays participants in its own token for contributing useful work. Each round, peers trained locally for thirty steps, compressed their pseudo-gradients, and uploaded them to cloud object storage; a validator scored submissions and selected the best for aggregation. The paper reported that, with assumed connections of 500 megabits per second down and 110 up, communication took about seventy seconds per twenty-minute round, roughly 94.5 percent utilization. At least seventy distinct peers contributed over the run. On standard benchmarks, Covenant-72B scored comparably to Meta's Llama 2 70B, a centralized model of 2023 trained on nearly twice as many tokens, beating it on some tests and trailing on others. What "decentralized" actually means These achievements are real, and the trajectory is steep: from a small Bengali model in 2021 to a 72-billion-parameter model roughly comparable to Llama 2 70B in 2026. But two qualifications are essential to understanding what has and has not been democratized. The first concerns who the participants are. The romantic image of decentralized training is thousands of gaming PCs pooled into a supercomputer. The reality is different. Each Covenant-72B peer was required to bring at least eight of Nvidia's B200 accelerators — hardware costing several hundred thousand dollars per node. INTELLECT-1's contributors ran H100 clusters. The algorithms reduce communication between nodes, but each node still has to hold and train a full copy of the model, which demands data-center hardware. What has been decentralized is coordination among owners of serious compute, spread across many data centers and organizations, not participation by ordinary people. That is still meaningful — it means a training run need not be owned or controlled by a single company, and can aggregate otherwise idle or fragmented capacity — but it is a different kind of democratization from the one the phrase suggests. Several projects are working on the next step: splitting a single model across participants so that no one needs to hold all of it. Pluralis Research, for example, has argued for "protocol learning," in which model-parallel training over the internet would mean no single participant ever possesses the full weights, potentially allowing contributors to share in ownership of the resulting model. Model-parallel training over slow links remains far harder than data-parallel training, and these efforts are at an earlier stage. The second qualification concerns scale. The frontier has not stood still while collective training improved. The leading closed and open-weight models of 2026 are trained with compute budgets thousands of times larger than any collective run, on tens of trillions of carefully curated tokens, followed by extensive reinforcement learning. Covenant-72B matched a centralized model from 2023. The gap between collective and centralized pretraining is not closing so much as maintaining a lag of a few years, which is roughly the same lag that open-weight models in general showed relative to closed models before the arrival of large Chinese releases. Trust, incentives, and the problem of free riders Decentralized training also has to solve problems that do not exist inside one company's data center. Participants must be motivated to contribute expensive compute, and the system must defend against those who contribute badly or maliciously. Incentives have largely come from cryptocurrency. Bittensor pays participants in its native token according to validators' assessments of their contributions; Psyche coordinates on Solana; other projects issue their own tokens or promise ownership stakes in resulting models. This is a pragmatic choice — blockchains offer a ready-made way to pay strangers without a central intermediary — and a controversial one, since it ties the economics of training to volatile token markets and attracts participants motivated by speculation rather than by the model. Whether token-funded training can sustain the multimillion-dollar compute budgets that competitive pretraining requires, through market cycles, is unproven. Verification is the technical side of the same problem. In a permissionless network, a participant could submit random noise, a lazily computed update, or a carefully crafted update that implants a backdoor. Systems such as Covenant's Gauntlet score each submission by checking whether it actually improves the model on held-out data, and discard or down-weight those that do not. TOPLOC uses compact fingerprints of a model's internal computations to verify that inference was done honestly. These mechanisms are clever and incomplete; the research literature on poisoning attacks against federated learning suggests that subtle, targeted manipulations can be very hard to detect from updates alone. Why it matters anyway It would be easy to dismiss decentralized training as a crypto-adjacent sideshow that will never catch the frontier. That would miss its significance for the open ecosystem. The central weakness identified in earlier chapters is that the open community depends on a few organizations choosing to release base models. Decentralized training is the only proposed mechanism by which a community, rather than a company or a state, could produce those bases itself. Even if it remains a few years behind the frontier, a model comparable to the best of two or three years ago, trained on documented data under an open license and owned by no single entity, would be a durable public good — a floor beneath which the open ecosystem could not fall, regardless of what any company decides. Hugging Face's own figures suggest that the median downloaded model remains under a billion parameters; most practical uses do not require the frontier. There is also a strategic argument. The efficiency techniques developed for decentralized training — infrequent synchronization, aggressive compression, tolerance for heterogeneous hardware — are useful to anyone who cannot build a single giant data center, including national research programs, university consortia, and companies stitching together capacity across regions. DeepMind's interest in DiLoCo was motivated by exactly such concerns about the limits of single-site training. If frontier training increasingly spans multiple sites for reasons of power supply alone, the gap between centralized and decentralized methods may narrow from the other direction. The honest summary is that decentralized training has moved from impossible to merely very hard. It has not yet pushed democratization upstream in the sense that matters most — letting a community without corporate sponsorship produce a competitive base model. But it has established that the first mile is not, in principle, the exclusive property of those who own the largest data centers. Whether the open ecosystem can exploit that depends not only on algorithms but on the legal and policy environment in which models are released, which is where the next two chapters turn. Chapter 7. The Fine Print: Open-Weight Licenses and What They Actually Permit When a developer downloads an open-weight model, a license comes with it, usually in a file that few people read. For hobbyists, that may not matter much. For a startup building a product, a hospital deploying a model, or a researcher redistributing a fine-tune, it can matter a great deal. The licenses attached to open-weight models form a spectrum running from the standard open-source licenses that software lawyers have understood for decades to bespoke documents written by individual companies, containing use restrictions, user thresholds, naming requirements, and clauses allowing the licensor to change the terms later. Behind them all sits a question that no court has squarely answered: whether model weights are protected by copyright at all, and therefore whether many of these licenses can be enforced against people who never agreed to them. Why licenses matter for the argument The book's central claim is that open weights have democratized the last mile. Licenses determine how much of that democratization is real for commercial users. A model with excellent weights and a license that forbids commercial use is, for a company, little better than a closed model. A model under a license with a revocable acceptable-use policy is a model whose permitted uses can shrink after a business has been built on it. A model whose license requires derivatives to carry its name gives the licensor branding leverage over the entire downstream ecosystem. Licenses are where corporate strategy shapes community freedom most directly. Table 5 compares the main license types in use, which the sections below discuss in turn. Table 5. Main license types applied to open-weight models. License Example models Commercial use Use restrictions Scale or revenue conditions Naming or attribution Apache 2.0 Mistral 7B, Qwen3, gpt-oss, Gemma 4, OLMo Yes None None Retain notices; explicit patent grant MIT DeepSeek-R1, GLM-4.5 Yes None Retain copyright notice Modified MIT Kimi K2 Yes None Display requirement above 100M monthly users or $20M monthly revenue "Kimi K2" shown in product interface above threshold Llama Community License (3.x) Llama 3.1, 3.2, 3.3 Yes Acceptable use policy, updatable by Meta Separate license needed above 700M monthly users "Built with Llama"; derivative names begin "Llama" OpenRAIL-M family Stable Diffusion 1.x, BLOOM, StarCoder Yes Listed harmful uses, passed on to derivatives None Must include restrictions in derivatives Stability AI Community License Stable Diffusion 3.5 Below threshold Acceptable use policy Enterprise license above $1M annual revenue Attribution required Standard open-source licenses The simplest case is a model released under a license written for software. The two most common are Apache 2.0 and MIT. The MIT License is a few short paragraphs. It permits anyone to use, copy, modify, merge, publish, distribute, sublicense, and sell the licensed work, provided the copyright notice and license text are included in copies. It disclaims all warranties. It says nothing about patents, use restrictions, or names. DeepSeek released R1 under MIT, as did Zhipu with its GLM-4.5 models; DeepSeek moved several earlier models that had carried a custom license to MIT as well. Apache 2.0, the Apache Software Foundation's license, is longer and more careful. It grants the same broad freedoms but adds an explicit patent license from each contributor, covering any patents they hold that their contribution would infringe, together with a defensive clause: anyone who sues alleging that the work infringes a patent loses their patent license. It requires that modified files carry notices stating they were changed and that a NOTICE file, if one exists, be preserved. Corporate legal departments generally prefer Apache 2.0 to MIT precisely because of the patent grant. Mistral's open models, most of Alibaba's Qwen releases since 2024, OpenAI's gpt-oss, Google's Gemma 4, and the Allen Institute's OLMo models use it. Neither license contains any restriction on what the model may be used for. Both satisfy the Open Source Definition's prohibition on discriminating against fields of endeavor. Their one awkwardness in the AI context is that they were written for source code, and terms such as "derivative works" and "source form" map imperfectly onto weights, fine-tunes, and distilled models. In practice, the community has treated Apache and MIT models as freely usable for any purpose, including commercial fine-tuning, redistribution, and training other models on their outputs, and the licensors have encouraged that reading. Kimi K2 illustrates a minor variant. Moonshot AI released it under the MIT License with one added clause: if the model or a derivative is used in a commercial product with more than 100 million monthly active users or more than 20 million dollars in monthly revenue, the product's interface must prominently display "Kimi K2." This is an attribution requirement for very large users rather than a restriction on use, and it leaves nearly every developer in exactly the position MIT would. The movement toward standard licenses has been one of the clearest trends of 2024 through 2026. Alibaba moved Qwen from a custom license with a user threshold to Apache 2.0. Google, after two years of criticism of its custom Gemma terms, moved to Apache 2.0 with Gemma 4. DeepSeek moved from a custom responsible-use license to MIT. The trend reflects competitive pressure: when strong models are available under Apache or MIT, a custom license is a cost that developers can avoid by choosing a competitor. The Llama Community License Meta's license deserves close reading, because for two years it was the most widely accepted license in the ecosystem and because it established many of the conventions that custom licenses have followed since. The Llama license grants a non-exclusive, worldwide, royalty-free license to use, reproduce, distribute, copy, create derivative works of, and modify the Llama materials. It then attaches conditions. The most discussed is the threshold: if, on the release date of the model version, the licensee's products had more than 700 million monthly active users, the licensee must request a separate license from Meta, which Meta may grant or refuse at its sole discretion. Almost no company exceeds that threshold except a small group of Meta's direct competitors — the clause is often read as aimed at Google, Apple, Microsoft, Amazon, ByteDance, and similar firms — so for nearly all developers it is irrelevant. It nonetheless violates the Open Source Definition's prohibition on discriminating against persons or groups, and it was one reason the Open Source Initiative stated publicly in 2023 that the Llama license was not an open-source license. The second condition is the acceptable use policy, incorporated by reference. It prohibits using Llama for a list of activities, including violating laws, engaging in or facilitating the planning of violence, generating child sexual abuse material, and certain military, weapons, and critical-infrastructure applications, among others. Critically, the policy lives on Meta's website and the license allows Meta to update it. A licensee's permitted uses are therefore not fixed at the moment of download. The policy's elasticity cuts both ways. In November 2024, Meta announced that it would make Llama available to United States government agencies and defense contractors for national security purposes — uses that its policy had appeared to prohibit — demonstrating that the licensor can widen permitted uses by announcement. It could equally narrow them. The third set of conditions concerns branding. Since Llama 3, the license has required that anyone distributing a Llama-based product or service display "Built with Llama" prominently, and that any model created by fine-tuning or otherwise improving a Llama model include "Llama" at the beginning of its name. The Llama 2 license prohibited using Llama outputs to improve any other large language model; the Llama 3.1 license reversed this, permitting the use of outputs for training other models, provided the naming requirement was met. The effect is to make Llama's lineage visible throughout the derivative ecosystem — a branding benefit to Meta that a standard license would not provide. Finally, Meta has used the license to make regional decisions. When it released the multimodal Llama 3.2 models in 2024, the acceptable use policy stated that the rights granted did not extend to individuals domiciled in, or companies with a principal place of business in, the European Union, a decision Meta attributed to regulatory uncertainty there. End users of products built by non-EU companies were not affected, but EU developers were cut off from those models. No standard open-source license could have done this. None of these provisions has been tested in public litigation. Their practical force comes less from courts than from the fact that large companies, which have the most to lose from a dispute, comply carefully, while small developers often do not read them at all. Responsible AI licenses A different family of licenses was designed not to protect a company's commercial position but to restrict harmful uses. The Responsible AI Licenses initiative, which began in 2018, proposed adding behavioral use restrictions to otherwise permissive terms. BigScience adopted the idea for BLOOM in 2022, and Stability AI used a variant, the CreativeML OpenRAIL-M license, for the original Stable Diffusion. BigCode used another for its StarCoder models. The distinctive feature of these OpenRAIL licenses is that their use restrictions propagate. Anyone who distributes the model or a derivative must include the same restrictions in their own license, so the restrictions follow the model through fine-tunes and redistribution, in a manner reminiscent of copyleft licenses such as the GNU General Public License — except that what propagates is a list of prohibited uses rather than an obligation to share source code. The restricted uses typically include violating laws, exploiting minors, generating disinformation intended to harm, discriminating against individuals or groups, providing medical advice without disclaimers, and fully automated decision-making that adversely affects legal rights. The arguments for this approach are straightforward: developers who release powerful models want some mechanism to express and, in principle, enforce limits on misuse. The arguments against are equally clear. The restrictions are vague, so licensees cannot be sure whether a given use is permitted. They are practically unenforceable against bad actors, who are the people they are aimed at and who are least likely to care about license terms. And they impose compliance costs on legitimate users while making the licensed models incompatible with the open-source tradition. The OpenRAIL approach has receded in prominence as major developers have moved toward standard licenses, though it remains common for image and video models and in academic releases. Commercial thresholds and other custom terms Between Llama's model and the RAIL licenses lies a range of bespoke documents. Several recurring patterns are worth knowing. Revenue and user thresholds. Stability AI's Community License, introduced in 2024, permits free commercial use by organizations with annual revenue under one million dollars and requires an enterprise license above that. Alibaba's earlier Qwen license required a separate license above 100 million monthly active users. These thresholds turn open weights into a freemium product: free for small users, paid for large ones. Non-commercial and research licenses. Some developers release weights for research or personal use only. Mistral introduced a Mistral Research License and a Mistral Non-Production License in 2024 for some models, including its Codestral coding model, while continuing to release others under Apache 2.0. Black Forest Labs released its FLUX.1 [dev] image model under a non-commercial license, while releasing a faster, distilled variant under Apache 2.0. Cohere released the weights of several Command R models under a Creative Commons non-commercial license. These releases support research and evaluation but leave commercial users needing a paid arrangement. Remote restriction and derivative definitions. Google's original Gemma Terms of Use, introduced in 2024, included a prohibited use policy and a clause reserving Google's right to restrict usage, "remotely or otherwise," of Gemma services it reasonably believed violated the terms. It also defined "model derivatives" broadly, to include models trained on Gemma's outputs through distillation, extending the terms' reach to models that contained no Gemma weights at all. Gemma 4's move to Apache 2.0 removed these provisions for the new models, though earlier Gemma versions remain under the original terms. Usage policies alongside standard licenses. OpenAI released gpt-oss under Apache 2.0 accompanied by a short usage policy asking users to comply with applicable law. Because the Apache license itself contains no use restrictions, the legal relationship between the license and the separate policy is ambiguous — another instance of a developer wanting the benefits of a standard license while signaling expectations about use. Chains of derivation Licenses become genuinely difficult when models are combined. A fine-tune of a Llama model is a derivative and must carry the Llama license and naming. A merge combining a Llama fine-tune with an Apache-licensed model must, at minimum, satisfy both — in practice, the more restrictive terms govern. A model distilled from Gemma under its original terms may be a "model derivative" subject to Gemma's restrictions even though it contains no Gemma weights. A model fine-tuned on outputs from a closed model may violate that provider's terms of service, which typically prohibit using outputs to develop competing models; OpenAI publicly raised such concerns about DeepSeek in early 2025. The Hugging Face Hub records a license field for each repository, but it is set by the uploader and frequently wrong for derivatives: merges of restrictively licensed models labeled as Apache, fine-tunes that omit the base model's terms entirely. A company assembling a product from community models may inherit obligations it cannot easily discover. Larger enterprises increasingly maintain approved lists of models with verified license chains, which again channels usage toward official releases from known developers. Are weights copyrightable? Underneath all of this sits a foundational uncertainty. Licenses grant permission to do things that would otherwise infringe the licensor's rights. If model weights are protected by copyright, a license defines what others may do with them, and someone who violates it is an infringer. If weights are not copyrightable, a license can operate only as a contract, binding only those who have agreed to it. There are serious arguments that weights are not copyrightable, at least in the United States. Copyright protects original works of authorship, and American law requires human authorship; the U.S. Copyright Office has repeatedly refused registration for material generated without sufficient human creative control. Weights are numbers produced by an optimization algorithm running over data. Humans chose the architecture, the data, and the hyperparameters, but no human chose any individual weight, and the arrangement of weights is dictated by the training process rather than by creative expression. On this view, weights resemble the output of a calculation more than a novel or a program. There are counterarguments. Software is copyrightable, and weights are functionally a part of software. The selection and arrangement of training data and training choices involve creative judgment that might be argued to carry through. In the European Union, a separate database right protects substantial investment in obtaining, verifying, or presenting the contents of a database, and some lawyers have argued it could apply to weights. Patents might cover particular architectures or methods, though not the weights themselves. And once weights are published, trade secret protection is gone. No court has yet ruled definitively on the question. The practical consequences of an answer would be large. If weights are not copyrightable, then someone who obtains weights without accepting the license — downloading them from a third-party mirror, for instance — may not be bound by its restrictions at all. This is one reason developers have used gated downloads requiring explicit acceptance of terms: it converts a license that may rest on uncertain property rights into a contract with a clear agreement. It is also why the LLaMA leak of 2023 was, legally, so murky. The people who downloaded the leaked weights had agreed to nothing. What the license landscape means For practitioners, the lesson is concrete: check the license of every model in a product's lineage, including base models and anything used to generate training data, and prefer standard licenses where capability is comparable. For the ecosystem, the lesson is structural. Licenses are the instrument by which base-model producers decide how much of the last mile they actually surrender. The shift toward Apache and MIT since 2024 represents a real expansion of community freedom, driven by competition among producers. It is also contingent on that competition. A producer that dominates without strong competitors has every incentive to tighten terms, and nothing in the current legal landscape prevents it from doing so for future releases. Licenses govern the relationship between producers and users. The relationship between producers and the state is governed by law, which the next chapter examines. Chapter 8. Openness Before the Law: Regulation, Exemptions, and Liability Regulating a technology usually means regulating the people who make and sell it. A car manufacturer must meet safety standards; a drug company must run clinical trials; a bank must hold capital. These regimes assume that there is an identifiable producer who controls the product and can be held responsible for how it performs. Open-weight models strain that assumption. Once weights are published, the original developer loses all control over how they are modified, deployed, or combined. Thousands of downstream actors fine-tune, merge, and serve them. Release is irreversible: there is no recall for a file mirrored on thousands of machines. Every jurisdiction that has tried to regulate advanced AI has had to decide what to do about this. The answers so far fall into three patterns: exempt open models from obligations that make little sense for them, regulate the largest developers regardless of release strategy, or treat openness as a strategic asset to be promoted. The particular mix a jurisdiction chooses tells you how it weighs the downstream democratization this book describes against the risks it carries. The structural problem Three features of open release complicate regulation. The first is the diffusion of responsibility. If a fine-tuned derivative of an open model causes harm, who is responsible? The original developer, who could not foresee or prevent the modification? The fine-tuner, who may be anonymous and in another country? The hosting platform? The deployer who put it in front of users? Rules designed for a single accountable provider fit poorly onto a chain of independent actors. The second is irreversibility. Closed-model providers can monitor usage, update safeguards, and withdraw models. Open-model developers can do none of these things after release. A regulator that wants the option to intervene after a problem emerges cannot have it for open weights. This is the core reason some safety advocates favor restrictions on release itself, discussed in Chapter 9. The third is the compliance burden on non-commercial actors. Many open models come from universities, nonprofits, and individuals who cannot afford the documentation, evaluation, and legal work that a large company treats as overhead. Rules written with large companies in mind can, if applied indiscriminately, push these actors out — reducing exactly the diversity and transparency that openness is supposed to provide. The European Union: exemption with a ceiling The EU's Artificial Intelligence Act, which entered into force in August 2024, is the most comprehensive AI law anywhere, and it treats open-source models with deliberate, if imperfect, care. Most of the Act regulates AI systems by their use, imposing obligations on high-risk applications such as hiring, credit scoring, and critical infrastructure. Those obligations fall on whoever deploys the system for that purpose, whether the underlying model is open or closed. A hospital that builds a high-risk diagnostic system on an open model bears the same obligations as one that uses a closed API. The Act's rules for general-purpose AI models, which apply from August 2025, are where openness matters. All providers of such models must maintain technical documentation, supply information to downstream developers who integrate the model into their own systems, adopt a policy to comply with EU copyright law — including respecting machine-readable opt-outs from text and data mining — and publish a sufficiently detailed summary of the content used for training, following a template the European Commission issued in July 2025. Models released under a free and open-source license that allows access, use, modification, and distribution, with weights, architecture, and usage information made public, are exempted from the first two obligations: the technical documentation and downstream information requirements. The logic is that public weights already allow downstream developers to inspect what they need. The exemption does not extend to the copyright policy or the training-content summary, so even fully open developers must say what they trained on, in summary form, and respect opt-outs. The exemption has two important limits. First, it does not apply to models with "systemic risk," a category the Act presumes for any model trained with more than 10^25 floating-point operations of compute, a threshold that the largest open releases now exceed. Providers of such models, open or not, must perform model evaluations including adversarial testing, assess and mitigate systemic risks, report serious incidents, and ensure adequate cybersecurity. Second, the Act's recitals indicate that the exemption is meant for genuinely free and open-source releases; models that are monetized through the license, such as by charging for use or tying use to the provision of paid services, may not qualify. Whether custom licenses with acceptable-use policies or user thresholds count as "free and open-source" is unsettled, and it gives the Llama-style licenses discussed in Chapter 7 a compliance consequence beyond their contractual effect. To help providers comply, the Commission facilitated a General-Purpose AI Code of Practice, published in July 2025, with chapters on transparency, copyright, and safety and security. Signing is voluntary; signatories gain a presumption of compliance. Most major developers signed. Meta publicly declined, arguing that the Code introduced legal uncertainties and went beyond the Act's scope — a stance consistent with its earlier withholding of multimodal Llama models from EU developers. The EU approach thus amounts to exemption with a ceiling: open release reduces paperwork for smaller models but buys no relief for the largest ones, and all open developers must engage with copyright and training transparency. For academic and small developers, that is a workable settlement. For producers of frontier-scale open models, it means the same core safety obligations as closed developers, with the added difficulty that they cannot rely on post-release monitoring or withdrawal to manage risk. The United States: from study to promotion American federal policy on open weights has moved through three phases in as many years. The first was study. President Biden's October 2023 executive order on AI directed the National Telecommunications and Information Administration to examine the risks and benefits of "dual-use foundation models with widely available model weights." The NTIA's report, released in July 2024 after a public comment process that drew hundreds of submissions, concluded that the evidence did not yet justify restricting the release of open weights. It recommended that the government build the capacity to monitor risks — collecting evidence, evaluating models, and defining indicators that would trigger a reassessment — while preserving the option to act if those indicators appeared. The report took the benefits seriously: competition, innovation, research, and the ability of smaller actors and other countries to participate. The second phase was a brief attempt at control at the edges. In January 2025, in its final week, the Biden administration issued an export-control framework for AI, sometimes called the diffusion rule, which among other things restricted the export of the weights of the most powerful closed models. It explicitly excluded published open weights from those restrictions, on the reasoning that controls on already-public information were unenforceable and that the best open models lagged the frontier. The incoming Trump administration revoked the 2023 executive order on its first day and rescinded the diffusion rule in May 2025, before its compliance obligations took effect. The third phase is promotion. America's AI Action Plan, released by the White House in July 2025, included a section titled "Encourage Open-Source and Open-Weight AI," arguing that open models have unique value for innovation, research, and adoption by businesses and governments that cannot send sensitive data to closed providers, and that the United States should ensure leading open models are founded on American values. The plan called for improving access to compute for researchers and startups and supporting the development of open models. Its framing was explicitly competitive: by 2025, the most widely used open-weight models were Chinese, and American policymakers had come to view the global adoption of Chinese base models as a strategic concern. The National Institute of Standards and Technology's Center for AI Standards and Innovation published an evaluation of DeepSeek's models later that year, highlighting performance gaps with American systems and the models' tendency to echo positions of the Chinese government on politically sensitive topics. Several federal agencies and states, meanwhile, banned DeepSeek's apps from government devices — restrictions aimed at the hosted service and its data flows rather than at the weights themselves. The upshot is that, for now, the United States does not regulate the release of open weights at the federal level, and its stated policy is to encourage them, while treating the national origin of base models as a matter of strategic interest. The states: California and the shape of frontier rules The sharpest American fight over open weights happened in California. In 2024, the state legislature passed SB 1047, which would have required developers of models trained with more than 10^26 operations at a cost above 100 million dollars to adopt safety protocols, test for capabilities that could cause critical harms such as mass-casualty attacks, and maintain the ability to fully shut down models under their control. Open-source advocates objected that the bill's provisions on derivatives and liability would make developers answerable for downstream modifications they could not control, and that the shutdown requirement was meaningless or chilling for released weights. Supporters noted that the bill's thresholds would affect only a handful of the largest developers and that its shutdown requirement applied only to copies in the developer's possession. Governor Gavin Newsom vetoed it in September 2024, arguing among other things that it focused on model size rather than on deployment in high-risk contexts. A year later, Newsom signed SB 53, the Transparency in Frontier Artificial Intelligence Act. It is a narrower, disclosure-based law. Developers of frontier models above the same compute threshold must publish information about their safety practices; the largest, with annual revenue above 500 million dollars, must publish a framework describing how they assess and mitigate catastrophic risks, report critical safety incidents to the state, and protect whistleblowers. SB 53 does not impose liability for downstream misuse or require shutdown capability, and its burdens fall on large companies regardless of whether they release weights. New York enacted a comparable frontier-model transparency law, the RAISE Act, at the end of 2025. At the federal level, the administration moved in late 2025 to challenge state AI laws it regarded as burdensome, leaving the durability of state regimes uncertain. The trajectory from SB 1047 to SB 53 illustrates where the political equilibrium has settled. Rules that would make open-weight developers liable for what others do with their models have proved politically unsustainable. Rules requiring the largest developers to be transparent about their safety practices, applied equally to open and closed releases, have passed. China: open weights inside a controlled information system China's approach is distinctive. Its Interim Measures for the Management of Generative AI Services, effective August 2023, apply to services offered to the public in China and require, among other things, that generated content uphold "core socialist values" and that providers file their algorithms with regulators. The measures regulate services, not weights; a model released for download is not itself a public service. But Chinese developers train their models to comply, because they also offer them as domestic services, and the compliance is baked into the weights. When DeepSeek-R1 was released, users quickly documented that it refused or deflected questions about subjects such as the 1989 Tiananmen Square crackdown, and community developers released versions fine-tuned to remove those behaviors; the search company Perplexity published one such variant, R1 1776, in early 2025. At the same time, Chinese industrial policy has embraced open-source AI as a way to build international adoption, attract developers, and reduce the effect of American export controls on chips by maximizing the value extracted from limited compute. The result is a regime that is restrictive about content and permissive, even promotional, about release — the mirror image of debates in the West, where release is the contested question and content is largely left to developers. Copyright as indirect regulation Some of the most consequential law affecting open models is not AI regulation at all, but copyright litigation over training data. Its effects fall unevenly on open and closed developers. In June 2025, two federal judges in San Francisco issued rulings in cases brought by authors. In Bartz v. Anthropic, Judge William Alsup held that training a model on lawfully acquired books was fair use, but that downloading and storing millions of pirated books was not; the case later settled for 1.5 billion dollars. In Kadrey v. Meta, Judge Vince Chhabria granted Meta summary judgment because the plaintiffs had failed to show market harm, while writing that the argument that AI-generated works could dilute the market for human writing might succeed in other cases. In the United Kingdom, the High Court ruled in November 2025 in Getty Images v. Stability AI that the Stable Diffusion model was not an "infringing copy" of Getty's photographs because its weights did not store or reproduce the works — a finding directly relevant to open-weight distribution. Days later, a Munich court reached a different conclusion on different facts in a case brought by the German music rights society GEMA against OpenAI, holding that a model's memorization of song lyrics constituted reproduction. These cases matter for open weights in two ways. If weights can be held to contain copies of training data, distributing them could itself be an act of infringement, a risk that falls on anyone who mirrors or redistributes a model. And transparency carries legal exposure. A developer who publishes its full training data, as fully open projects do, hands potential plaintiffs a precise list of what it used. A developer who publishes only weights discloses much less. The EU's training-content summary requirement narrows this gap somewhat, but the incentive remains: copyright risk pushes developers toward releasing weights while keeping data secret — exactly the configuration that Chapter 1 identified as the dominant one, and the one least useful for reproducing models upstream. What the law has settled, and what it has not Across jurisdictions, a rough consensus has emerged on a few points. Release of open weights below the frontier is not restricted anywhere among the major AI powers. Obligations tied to specific high-risk uses apply to deployers regardless of whether the model is open. The largest developers face transparency and safety obligations whatever their release strategy. And liability for downstream modifications by unrelated parties has not been imposed on original developers. Much remains unsettled. No regime has a satisfactory answer to how safety obligations should work for frontier-scale open models, whose developers cannot monitor or withdraw them. The meaning of "open source" for legal purposes remains contested. The copyright status of weights and training is being decided case by case, in different directions in different countries. And policy toward open weights has become entangled with geopolitical competition in ways that could shift quickly — toward promotion if open models are seen as instruments of national influence, or toward restriction if a serious incident is traced to a released model. That second possibility is the subject of the next chapter. Chapter 9. The Safety Objection: Marginal Risk, Stripped Safeguards, and Irreversible Release The strongest argument against open weights is simple. A closed model sits behind an interface its developer controls. The developer can refuse dangerous requests, watch for patterns of abuse, ban malicious users, patch problems as they are discovered, and withdraw the model entirely if necessary. An open model can be downloaded, modified to remove its refusals, and run on private hardware where no one is watching. Whatever safeguards its developer built in can be undone, and whatever capabilities it has are available, permanently, to everyone, including the worst actors on earth. If a model is capable enough to provide meaningful help with building a biological weapon or attacking critical infrastructure, releasing its weights hands that help to anyone who wants it. That argument deserves a serious answer rather than dismissal, and the open community has not always given it one. The answer that has emerged from research and policy work since 2023 is neither "open models are safe" nor "open models are dangerous," but a framework for asking how much additional risk a particular release creates, and an increasingly detailed body of evidence about how easily safeguards can be removed and what can be done instead. Thinking in marginal terms The most influential framework came from a 2024 paper, "On the Societal Impact of Open Foundation Models," by Sayash Kapoor, Rishi Bommasani, and colleagues from Stanford, Princeton, and other institutions. It identified five properties that distinguish open from closed models: broader access, greater customizability, the ability to run locally, the inability to rescind access once granted, and the inability to monitor or moderate use. Each property produces both benefits and risks. Local inference protects privacy and also escapes oversight. Customizability enables specialization and also enables removing safeguards. The paper's central contribution was to insist on marginal risk: not whether a model could be misused, but how much an open release increases risk compared with the world as it would exist without that release. That comparison requires asking what a bad actor could already do with closed models, search engines, published literature, and existing tools; what defenses already exist against the threat; and what evidence there is that the open model provides meaningful uplift beyond those baselines. Applying this lens to prominent claims about open-model risks, the authors found that most analyses had not established marginal risk, often because they compared an open model with nothing rather than with readily available alternatives. The framework cuts both ways. It discounts alarm about capabilities that are already widely available — an open model that can write phishing emails adds little to a world in which closed models, templates, and criminal services already do so cheaply. But it takes seriously capabilities that are genuinely new and hard to obtain elsewhere. And it treats the inability to recall a release as a real cost: a closed model found to be dangerous can be withdrawn, while an open one cannot, so the uncertainty about future misuse weighs more heavily for open release. How easily safeguards come off The evidence on removing safeguards from open models is clear and consistent: it is easy. In late 2023, several research groups demonstrated this independently. Simon Lermen, Charlie Rogers-Smith, and Jeffrey Ladish showed that LoRA fine-tuning could undo the safety training of Meta's Llama 2-Chat 70B model for less than 200 dollars of compute on a single GPU, producing a model that complied with harmful requests while retaining its general capabilities. A team led by Xiangyu Qi at Princeton showed that even closed models offered through fine-tuning APIs were vulnerable: fine-tuning OpenAI's GPT-3.5 Turbo on just ten adversarially designed examples, at a cost of under 20 cents, substantially removed its refusals. More troublingly, they found that fine-tuning on entirely benign datasets could also degrade safety behavior, without any intent to do so. In 2024, Andy Arditi and colleagues showed that refusal in a range of open chat models up to 72 billion parameters is mediated by a single direction in the model's internal activations. Identify that direction by comparing activations on harmful and harmless prompts, remove it from the model's weights, and the model stops refusing — no fine-tuning required, only a few minutes of computation. The open community quickly turned the method into a routine procedure, which it called "abliteration," and abliterated versions of popular models appeared on the Hugging Face Hub within days of their release. The lesson is that refusal training, the main safeguard closed developers rely on at the model level, is shallow. It teaches the model when to decline, but it does not remove the underlying knowledge or capability. For an open model, safety behavior is best understood as a default setting that any determined user can change. This is precisely why marginal risk analysis focuses on capabilities rather than safeguards: for an open release, one should assume that whatever the model can do, a motivated actor will be able to make it do. What the evidence says about harm If safeguards come off easily, the question becomes what harms have actually followed from open release, and what harms might follow as capabilities grow. The clearest documented harms are not the catastrophic scenarios that dominate policy debates, but abuses of image generation. Fine-tuned versions of open image models have been used extensively to produce non-consensual sexual imagery of real people and, gravely, synthetic child sexual abuse material. The Internet Watch Foundation, a British organization that tracks such material, has documented growing volumes of AI-generated abuse imagery since 2023, much of it produced with locally run open models that had been fine-tuned for the purpose. In December 2023, the Stanford Internet Observatory reported finding more than three thousand suspected instances of child sexual abuse material in LAION-5B, the open dataset of image-text pairs used to train early Stable Diffusion models; LAION withdrew the dataset and later released a cleaned version, and a widely used Stable Diffusion checkpoint was removed from Hugging Face in 2024. These harms are real, concentrated, and largely attributable to open models specifically, because closed image services filter both requests and outputs. They have prompted criminal law changes in several countries targeting the creation and distribution of such material, an approach that regulates use rather than release. For language models, the evidence on catastrophic misuse is more ambiguous. A 2024 red-team study by the RAND Corporation found no statistically significant difference in the viability of biological attack plans produced by teams with access to the language models of 2023 compared with teams using only the internet. But capabilities have advanced since then. In 2025, both Anthropic and OpenAI announced that their newest closed models had reached capability levels in biology that, under their own frameworks, warranted heightened safeguards, as a precaution against meaningful uplift to novices seeking to cause harm. Those safeguards rely heavily on the developer's control: classifiers that screen requests and responses, monitoring, and account enforcement. None of them transfer to a downloaded model. That observation leads directly to the strongest version of the safety argument for the present moment. The question is not whether today's open models are dangerous, but what happens when open models reach the capability levels at which closed developers now judge such safeguards necessary. Given the historical lag of open models behind closed ones — estimated by the research group Epoch AI in 2024 at roughly a year on standard benchmarks, and arguably shorter since the arrival of large Chinese releases — that moment is not far off, if it has not already arrived. Evaluating worst cases before release The responsible response from developers has been to evaluate open models against the assumption that safeguards will be removed. When OpenAI released gpt-oss in August 2025, it published a study of what it called malicious fine-tuning: its own researchers deliberately fine-tuned the model to maximize its capabilities in biology and cybersecurity, simulating what a well-resourced adversary might do, and then measured the result against its Preparedness Framework thresholds. The company reported that even the adversarially fine-tuned model did not reach the "high" capability threshold in those domains, and that it did not significantly advance the frontier of capabilities already available in open models. That approach — evaluating the worst plausible version of a model rather than the version as shipped — is the appropriate standard for open release, because it is the version that bad actors will use. Meta, too, published a Frontier AI Framework in early 2025 committing not to release models whose evaluations indicated they could provide critical uplift toward catastrophic outcomes, and to halt development of models above a critical risk threshold. The framework acknowledged openly that release decisions would depend on capability evaluations, an implicit recognition that the company's open-weight commitment had limits. Safety in the weights themselves If refusal training is shallow, can safety be built deeper? Several research directions attempt it, with mixed results. Unlearning aims to remove specific dangerous knowledge from a model after training. The Weapons of Mass Destruction Proxy benchmark, released in 2024 by the Center for AI Safety and collaborators, measured hazardous knowledge in biosecurity, chemical security, and cybersecurity, alongside a method for reducing it. But subsequent research found that knowledge apparently removed by unlearning methods could often be recovered by small amounts of fine-tuning, suggesting the knowledge had been suppressed rather than erased. Tamper-resistant training attempts to make safeguards survive fine-tuning by training the model, in effect, against simulated fine-tuning attacks. A 2024 method called TAR showed resistance to many attacks, but later work found configurations that circumvented it. The broad pattern in this research has been a cycle of defense and attack in which defenses raise the cost of removal without making it impossible. Data filtering takes a more fundamental approach: if a model never learns dangerous knowledge during pretraining, there is nothing to unlock. In 2025, researchers at EleutherAI and the UK AI Security Institute reported that filtering text related to biological threats from pretraining data produced models that resisted adversarial fine-tuning on that topic far better than models with post-hoc safeguards, while largely preserving general capabilities. This approach has an appealing logic and an important implication for the book's argument: it is a safety measure that operates at the first mile, during pretraining, which means only those who control pretraining can apply it. A community that only fine-tunes cannot add it after the fact, and a community that trains its own bases must take responsibility for it. Benefits that the safety case must weigh The safety debate is not one-sided, and the benefits of openness bear directly on safety itself. Interpretability research — the effort to understand how models compute — depends on full access to weights and activations. Google DeepMind's release of Gemma Scope in 2024, a large set of tools for decomposing the internal representations of its open Gemma models, enabled external researchers to study model internals in ways impossible with closed systems. The refusal-direction finding described above, which revealed a weakness in safety training, was itself a product of open-weight research; understanding why safeguards fail is a prerequisite to building better ones. Independent evaluation depends on openness too. Researchers can test open models without permission, publish results without negotiating with the developer, and reproduce each other's findings. Security researchers can probe open models for vulnerabilities, and defenders can use them for tasks such as analyzing malware without sending sensitive samples to a third party. Organizations that cannot share data with external providers — hospitals, defense agencies, banks — can deploy capable models without the privacy risks of an API. Openness also distributes power. A world in which only a few companies control capable AI concentrates a different kind of risk: the risk that those companies, or the governments that oversee them, use their position badly. Advocates of open weights argue that broad access is a check on that concentration. This argument is difficult to quantify, but it is not trivial, and it explains why some of those most concerned about AI's societal effects support openness rather than opposing it. A conditional answer The evidence supports a conditional position rather than a categorical one. For models whose capabilities are already broadly available from other sources — which, by the marginal-risk logic, includes most open releases to date — the benefits of openness have plausibly outweighed the added risks, with the significant exception of image models' role in sexual abuse imagery, where harms have been concrete and severe. For models approaching capability levels that closed developers judge to require deployment-time safeguards in domains such as biology, the calculation changes, because open release forfeits exactly the safeguards those developers rely on. What follows for practice is a set of norms that responsible open developers have begun to adopt: evaluate the worst plausible fine-tuned version of a model before release, not the shipped version; publish those evaluations; consider pretraining-level interventions such as data filtering for the most hazardous domains; and recognize that release decisions for the most capable models will be made one at a time against evidence, not settled by principle. Irene Solaiman's 2023 analysis of the "gradient" of generative AI release options — from fully closed through staged, gated, and API-based access to fully open — remains a useful reminder that the choice is not binary. For the book's argument, the safety question has a sharp implication. As open models approach the frontier, the case for releasing their weights depends increasingly on decisions made during pretraining: what data was included, what was filtered, what evaluations were run. Safety, too, lives upstream. A community that wants to keep the frontier open must eventually be able to take responsibility for the first mile, not only the last. Chapter 10. Why Give It Away? The Economics of Release and the Meaning of a Democratized Frontier Training a competitive base model costs tens of millions of dollars at the low end and hundreds of millions or more at the frontier, once research, failed experiments, data, and staff are counted alongside the final run. Releasing its weights gives that investment away. Competitors can use it; customers who might have paid for an API can run it themselves; the developer captures nothing directly. Yet a dozen organizations do this repeatedly. Understanding why is essential to judging how durable the open ecosystem is, because every chapter of this book has returned to the same dependence: the derivative layer exists only as long as base-model producers find release worthwhile. Commoditizing the complement The oldest explanation comes from software strategy. In a 2002 essay, the software entrepreneur Joel Spolsky observed that smart companies try to commoditize their products' complements — the goods that customers buy alongside their own. If you sell operating systems, you want cheap hardware; if you sell hardware, you want free software. Driving the price of a complement toward zero increases demand for your own product and prevents anyone else from capturing the value in that layer. Meta's open-weight strategy fit this logic precisely. Meta does not sell access to AI models; it sells advertising across social applications used by billions of people. For Meta, a world in which a few other companies controlled the best AI models, and could charge for them or shape the platforms through which people accessed them, would be dangerous. A world in which capable models were free and abundant would let Meta build AI features into its products without depending on a rival, and would deny competitors the chance to turn model access into a chokepoint. Mark Zuckerberg's 2024 letter made the argument almost explicitly, citing Meta's experience with open hardware designs through the Open Compute Project and the PyTorch framework, both of which Meta had released and which became industry standards that lowered its own costs. Open weights also brought Meta free engineering: the community's optimizations to inference, quantization, and fine-tuning were built first for Llama, and Meta's own products benefited. Similar logic applies elsewhere. For Alibaba, Qwen models are a complement to Alibaba Cloud. Every developer who builds on Qwen is a potential cloud customer, and an open model that runs best on Alibaba's infrastructure — or that simply puts Alibaba's name in front of developers worldwide — pulls demand toward its core business. For Nvidia, which has released its own open models and datasets, cheap and abundant models are a complement to the GPUs needed to run them. For Google, small Gemma models complement the Gemini platform and its cloud, and give developers who want local models a reason to stay within Google's ecosystem rather than adopting a competitor's. Market entry, talent, and standards A second set of motives concerns position rather than complements. For a new entrant, open release is marketing that no advertising budget can buy. Mistral's 2023 torrent drops turned a months-old startup into a household name among developers and helped it raise large funding rounds; its later strategy, mixing Apache-licensed models with commercial ones, followed the classic open-core pattern of software companies that give away a capable base product and sell premium versions and services. DeepSeek, largely unknown outside China before December 2024, became one of the most discussed AI organizations in the world within weeks of releasing V3 and R1. Open release also attracts talent. Researchers want their work to be used and cited, and many prefer employers who let them publish. DeepSeek's founder, Liang Wenfeng, told an interviewer in 2024 that the moat created by closed source is temporary and that what endures is a team's capacity to keep innovating, a view in which openness is a recruiting and cultural asset rather than a giveaway. Open release sets standards, too. When the community adopts a model's architecture, chat format, and tokenizer, tooling grows up around them, and the developer's choices become defaults that later competitors must accommodate. National strategy For Chinese developers in particular, open release has served purposes beyond any single company's interest. American export controls since 2022 have restricted China's access to the most advanced AI chips. Open release responds to that constraint in several ways. It maximizes the global influence extracted from limited compute: a model downloaded and fine-tuned by developers around the world spreads Chinese technology and standards far beyond what a domestic API could. It attracts international developer communities whose improvements flow back into the ecosystem. And it undercuts the pricing power of American closed providers, compressing the margins that fund their next generation of models. By early 2026, Chinese models accounted for a plurality of downloads on the Hugging Face Hub, and the Qwen family had become the most popular base for derivatives worldwide. This dynamic changed the politics of openness in the United States. In January 2025, after DeepSeek-R1's release, OpenAI's chief executive Sam Altman said in a public question-and-answer session that he personally believed the company had been "on the wrong side of history" on open source and needed a different strategy. Seven months later OpenAI released gpt-oss. America's AI Action Plan framed open models as a field in which the United States needed to lead. Openness, once a stance associated with academic idealism, had become an instrument of industrial and geopolitical competition. When the logic stops working Each of these motives has conditions, and when the conditions change, so does the calculus. Meta's trajectory illustrates this vividly. The complement strategy works as long as releasing models does not threaten the releaser's own position. When Meta believed it could not lead the frontier on its own, giving away near-frontier models denied that frontier to competitors at modest cost. But when the company decided in 2025 to compete directly for the frontier — reorganizing its AI efforts under Meta Superintelligence Labs, making a large investment in the data-labeling company Scale AI and bringing in its chief executive, Alexandr Wang, to lead the new organization, and committing to enormous capital spending on data centers — the calculation shifted. A model meant to be the best in the world is not a complement to be commoditized; it is the product. Zuckerberg wrote in mid-2025 that the company would need to be careful about what it chose to open source as models became more capable. In April 2026, Meta launched Muse Spark, its first flagship model released without open weights, and no new open Llama family appeared in the first half of the year. The general lesson is that a producer's willingness to release tends to be inversely related to its confidence that it can lead. Labs that trail release to gain position; labs that lead keep their best work closed. This creates a natural rhythm in the ecosystem: openness is supplied most generously by organizations in the chasing pack, and the identity of those organizations changes over time. Today it includes the major Chinese labs, Google for its smaller models, and OpenAI for a specific tier. Tomorrow it may not. The open-weight frontier has not collapsed with Meta's retreat, because other producers filled the gap — DeepSeek's V4 previews in April 2026, at 1.6 trillion total parameters, and Alibaba's Qwen 3.5 and 3.6 families continued to push open capabilities forward. But the episode demonstrates that the supply of open bases depends on the strategic situation of a small number of organizations, any of whom can change course. The cost curve and who can afford the first mile How expensive is the first mile, and is it getting cheaper? The answer depends on what you mean by the first mile. Training a model of fixed capability is getting dramatically cheaper. Algorithmic improvements — better architectures, better data filtering, mixture-of-experts designs, low-precision training — combine with hardware improvements to reduce the compute required to reach a given level of performance. DeepSeek-V3's reported final-run cost of about 5.6 million dollars, for a model that matched the best open models of the time and approached closed ones on many benchmarks, illustrated how far efficiency had come, even granting that the figure excluded research, failed runs, staff, and the capital cost of DeepSeek's own clusters. A model as capable as GPT-3 of 2020, or the original Llama of 2023, can now be trained by a well-funded university lab or a startup. Training a model at the frontier, however, is getting more expensive. The amount of compute used in the largest training runs has grown by roughly four to five times per year for more than a decade, according to Epoch AI's tracking, and the leading labs are building data centers measured in gigawatts and costing tens of billions of dollars. Each efficiency gain is reinvested in larger models and more training, rather than banked as savings. The frontier moves away from would-be followers at roughly the rate that efficiency gains bring yesterday's frontier within reach. This produces the pattern that recurs across the book. The capability that a community, a university, or a mid-sized country can produce on its own is rising rapidly. The gap between that capability and the frontier is not shrinking much, because the frontier is rising too. Democratization of the first mile is real but always lagging. Public money and sovereign models One response is to treat the first mile as public infrastructure, funded like roads or research universities. Several governments and public institutions have moved in this direction. Switzerland's Apertus models, released in 2025 by EPFL, ETH Zurich, and the Swiss National Supercomputing Centre, were trained on a public supercomputer with a fully documented data pipeline that respected website opt-outs, in sizes of 8 and 70 billion parameters with broad multilingual coverage. In the United States, the National Science Foundation and Nvidia announced in 2025 a combined commitment of more than 150 million dollars to support the Allen Institute for AI's development of fully open models for science. The European Union funded OpenEuroLLM, a consortium of universities, research centers, and companies working on open multilingual models for European languages. South Korea launched a sovereign AI initiative in 2025, selecting domestic teams to build national foundation models, and several of their models trended together on the Hugging Face Hub in early 2026. The UAE has continued funding open models through its Technology Innovation Institute and through the Mohamed bin Zayed University of Artificial Intelligence. India's national AI mission has funded domestic foundation models aimed at Indian languages. These efforts share three features. They tend to be fully open, publishing data and code as well as weights, because their purpose is public benefit rather than market position. They tend to target capabilities that commercial producers underserve, such as smaller languages, scientific domains, or legal compliance with local rules. And they tend to trail the commercial frontier, sometimes considerably, because public budgets are a fraction of the capital that leading companies deploy. Their importance lies less in competing at the frontier than in establishing a floor: a supply of capable, fully open bases that does not depend on any company's strategy. What "democratizing the frontier" can mean The phrase "democratization of frontier models" appears constantly in discussions of open AI, often without definition. The analysis of this book suggests that it can mean four different things, which have been achieved to very different degrees. Access to use means that anyone can run a near-frontier model. This has largely been achieved, through two channels. Directly, open weights for very large models are available for download, though running a 1.6-trillion-parameter model requires data-center hardware. Indirectly, competitive inference providers serve those weights at prices close to hardware cost, so anyone with a credit card can use them, and distillation brings much of their capability down into smaller models that run on consumer hardware. DeepSeek's release of R1 alongside six distilled models, from 1.5 to 70 billion parameters, put reasoning capabilities onto laptops within days of their appearance at the frontier. Access to adapt means that anyone can specialize such a model for their purposes. This, too, has been achieved, through the parameter-efficient methods and toolchains of Chapters 3 and 4. Adapting a strong open model to a domain or task costs little, and the derivative layer's two million repositories testify to how widely that capacity is used. Access to produce means that actors other than a few large organizations can create frontier-class base models. This has not been achieved. Decentralized training produces models a few years behind; public programs produce models that trail commercial ones; the first mile at the frontier remains the province of organizations able to spend billions. Access to govern means that the public, or at least a broad set of stakeholders, has a say in how frontier models are built — what data they use, what values they encode, what risks are acceptable. This has barely begun. Open weights allow outsiders to inspect and evaluate models after the fact, which is a meaningful form of accountability. But the decisions that shape a model are made during pretraining and post-training by the developer, and open release does not change who makes them. The open-source AI movement has delivered the first two forms of democratization with remarkable speed and breadth. It has not delivered the third or fourth, and the economics of the frontier suggest that it will not do so through market forces alone. Who captures the value A final economic question concerns who profits from the open ecosystem. Base-model producers capture value indirectly, through complements, position, and talent. Hardware makers capture it directly, since every downloaded model must run on someone's chips. Inference providers capture a margin on serving open models, though competition compresses it. Hugging Face captures it as the ecosystem's central platform, selling enterprise services and compute. And an enormous number of businesses capture it by building products on free models instead of paying API fees — the largest and most dispersed benefit of all. What is notably absent from this picture is a mechanism for the derivative layer to fund the base layer. The community that fine-tunes, quantizes, merges, and evaluates contributes enormous value, but none of it flows back to pay for the next generation of bases. In open-source software, foundations, corporate sponsorships, and the relatively low cost of writing code allowed communities to sustain projects independently. In open AI, the cost of the base layer is too high for those mechanisms, so it is funded by companies pursuing strategies and by states pursuing policies. This, finally, is the economic core of the book's argument: the open ecosystem's downstream abundance rests on an upstream supply that the ecosystem itself does not pay for and cannot guarantee. Conclusion: Downstream Abundance, Upstream Dependence Return to the spring of 2023 and the leaked Google memo that warned the open community was lapping the large labs. Three and a half years later, its prediction looks half right in a precise way. The open community did outpace the labs at everything that happens after pretraining. It built the fine-tuning methods, the quantization formats, the local inference engines, the merging tools, the evaluation harnesses, and the hub that ties them together, and it did so faster and more inventively than any single organization could have. But it never acquired its own source of base models at the frontier. It traded dependence on closed APIs for dependence on a different and shifting set of benefactors. The chapters of this book have examined that situation from several angles, and together they support a set of conclusions that could not be drawn from any one of them. What has been won, and why it will last The democratization of the last mile is real, and much of it is irreversible. Weights that have been released cannot be recalled; a capable model downloaded today will still run in ten years. The techniques that made adaptation cheap — low-rank adaptation, 4-bit quantization, direct preference optimization, training-free merging — are published, implemented in open libraries, and understood by tens of thousands of practitioners. Even if every base-model producer stopped releasing tomorrow, the existing stock of open models, which already includes systems comparable to the closed frontier of eighteen months or two years ago, would continue to support an enormous range of uses. A hospital that needs a private model to summarize clinical notes, a translator working in a language commercial providers neglect, a researcher studying how models represent concepts internally: none of them needs the next frontier release to do their work. The licensing environment has also improved in a way that matters for commercial users. The movement from custom licenses toward Apache 2.0 and MIT, driven by competition among producers, means that most of the strongest open models can now be used, modified, and built into products without negotiating with anyone or reading a bespoke legal document. Public policy, for now, protects release below the frontier in every major jurisdiction. These are substantial achievements. Where the vulnerability lies The vulnerability is upstream, and it has three dimensions. The first is strategic dependence. The supply of open base models depends on the calculations of perhaps a dozen organizations, each of which releases for reasons that can change. Meta's turn toward a closed flagship in 2026 showed how quickly the leading Western champion of open weights could recalibrate once it decided to compete for the frontier. The ecosystem absorbed that shift because Chinese producers were releasing comparable or better models under better licenses. A future in which those producers also pulled back, whether for commercial reasons or because of government pressure, would leave the open community with an aging stock and no means of renewing it at the frontier. The second is knowledge dependence. Chapter 3 showed that parameter-efficient methods excel at shaping behavior but are weak at adding knowledge; Chapter 9 showed that the most promising safety interventions operate during pretraining. Both findings mean that the most consequential properties of a model — what it knows, what it was never taught, what values and blind spots are embedded in its training data — are fixed by whoever controls the first mile. Fine-tuners inherit them. The third is legal fragility. The copyright status of weights is undecided. The legality of training on copyrighted material is being settled case by case, in different directions in different countries. Custom licenses can change for future releases at the producer's discretion. And the incentives created by copyright exposure push developers toward releasing weights while concealing data — the configuration least useful for anyone who wants to reproduce or continue a model's lineage. What follows for each participant If the analysis is right, it implies different things for different readers. For developers and companies building on open models, the practical upshot is to treat base models as replaceable. Adapters are tied to a specific base and become worthless when you migrate; datasets, evaluation suites, and pipelines are portable and retain their value across generations. Invest in the assets that survive a change of base. Prefer permissively licensed models where capability is comparable, and audit the full license chain of anything you deploy, including any model used to generate training data. Restrict sensitive deployments to official releases and trusted conversions, because provenance in the long tail of the hub cannot be verified. For companies that benefit from open models without producing them — which now includes a very large share of the software industry — there is a collective-action problem worth naming. The derivative economy draws enormous value from base models it does not fund. Contributing upstream, through open datasets, evaluation infrastructure, compute grants to fully open projects, or participation in collective training efforts, is the most direct way to reduce the dependence described in this book. Some companies already do this. Many more free-ride. For policymakers, three conclusions stand out. First, the case for keeping release legal below the frontier is strong: the marginal risks of most open models have been modest, the benefits broad, and attempts to impose downstream liability on original developers have rightly failed. Second, at the frontier, the right instrument is not a ban on release but a requirement — or at least a firm norm — that developers evaluate the worst plausible fine-tuned version of a model before release and publish the results, as some developers have begun to do voluntarily. Third, if governments believe that a supply of open base models is a public good, as the evidence in this book suggests it is, they should fund it as one: fully open pretraining on public compute, with documented data, as Switzerland, the United States through the National Science Foundation, the European Union, and South Korea have begun to do. Such programs will trail the frontier. Their job is to set a floor that does not depend on any company's strategy. Clarifying the law on text and data mining and on the copyright status of weights would also help, whatever direction the clarification takes, because uncertainty itself favors large incumbents who can absorb litigation. For the open community itself, the lesson is that its most valuable contributions to independence are the least glamorous ones. The open datasets of Chapter 5 — FineWeb, Dolma, The Stack, Common Corpus — and the fully open training recipes of projects like OLMo and Pythia are what make the first mile reproducible. Decentralized training, despite its hype and its ties to token markets, is the only proposed mechanism by which a community without a corporate or state sponsor could produce its own bases, and its progress from a small Bengali model in 2021 to a 72-billion-parameter model in 2026 is steep enough to take seriously. These are the efforts that push democratization upstream. Another thousand merges of the same base do not. What remains unsettled Several questions cannot be answered yet, and the reader should watch them. The first is whether frontier-capability models will be released openly as they approach the levels at which closed developers judge deployment-time safeguards necessary. Some producers have committed to evaluating before releasing; none has yet faced a clear case where evaluations said no. How that first case is handled will shape the policy environment for years. The second is whether decentralized training can close the gap to the frontier or will settle permanently a few years behind. The algorithms have improved faster than almost anyone expected. The economics — who pays, through what mechanism, across market cycles — are unproven. The third is whether the geographic center of open weights will remain in China. That depends on Chinese industrial policy, on American policy toward both its own developers and foreign models, and on whether Western producers decide that open release serves their competitive position. Users of open models have so far been largely indifferent to national origin when the weights are good and the license permissive. Governments are not indifferent, and that tension has not been resolved. The fourth is what "open" will come to mean legally. The Open Source Initiative's definition, the EU AI Act's exemption, and the licenses producers actually use all draw the line in different places. Eventually courts and regulators will have to decide whether a model with an acceptable-use policy, or one released without any description of its data, counts as open source for purposes that carry real consequences. The shape of a mature ecosystem A healthy open AI ecosystem would look different from the one that exists today in one respect above all: it would have more than one way to produce its bases. Commercial producers releasing for strategic reasons would remain the main source of near-frontier weights, as they are now. But beneath them would sit a layer of fully open models — trained on public compute, by public institutions, or by decentralized collectives, with documented data and permissive licenses — that trailed the frontier by a known and tolerable margin and could not be withdrawn by anyone's change of strategy. The derivative community would build on whichever base served best, confident that a floor existed beneath it. The open community has already shown that when capable weights exist in public, thousands of people will make them cheaper, smaller, more specialized, and more useful than their creators imagined. The question for the next decade is whether that same community, and the institutions that support it, can make the creation of those weights a shared undertaking too. The last mile has been democratized. The first mile is still owned. Everything in the future of open AI depends on how much of that ownership can be shared. Glossary Abliteration. A community technique for removing a model's tendency to refuse requests by identifying the internal direction associated with refusal and subtracting it from the weights, without fine-tuning. Acceptable use policy. A list of prohibited applications attached to a model license, often incorporated by reference and updatable by the licensor. Adapter. A small set of trainable parameters added to a frozen model during fine-tuning. A LoRA adapter is the most common type and is distributed as a separate file. DiLoCo. Distributed Low-Communication training, a method in which workers train independently for many steps and synchronize only occasionally by averaging how far their weights have moved. Distillation. Training a smaller or different model on the outputs of a stronger one, so that it imitates the stronger model's behavior. Fine-tuning. Continuing to train a pretrained model on a smaller, targeted dataset to change its behavior or specialize it. Fully open model. A model released with its weights, training code, and training data or detailed data documentation, under open licenses. GGUF. A single-file format for quantized models used by llama.cpp and tools built on it, designed to run on CPUs, Apple hardware, and consumer GPUs. LoRA. Low-Rank Adaptation: fine-tuning by freezing a model's weights and learning a pair of small matrices whose product is added to each targeted weight matrix. Marginal risk. The additional risk created by releasing a model, measured against what malicious actors could already do with existing tools and models. Mixture of experts (MoE). An architecture in which each token is processed by only a subset of the model's parameters, so the active parameter count is much smaller than the total. Model merging. Combining the weights of two or more models, usually fine-tunes of the same base, by arithmetic and without further training. Open-weight model. A model whose trained weights are publicly downloadable, regardless of the license attached or whether code and data are released. Parameter-efficient fine-tuning (PEFT). The family of methods, including LoRA, that adapt a model by training only a small fraction of its parameters. Pretraining. The initial, compute-intensive phase in which a model learns from trillions of tokens of general data; the "first mile" in this book's terms. Pseudo-gradient. In low-communication training, the difference between a worker's weights after local training and the last shared weights, used in place of a per-step gradient. QLoRA. LoRA training on top of a base model stored in 4-bit precision, allowing very large models to be fine-tuned on a single GPU. Quantization. Storing a model's weights in fewer bits than they were trained with, reducing memory use and increasing inference speed at some cost in accuracy. Safetensors. A model file format that stores only tensor data and metadata and cannot execute code on loading, replacing older formats that could. Weights. The learned numerical parameters of a neural network; in practical terms, the model itself. Further Reading Techniques Edward J. Hu et al., "LoRA: Low-Rank Adaptation of Large Language Models" (2021). The paper that made fine-tuning cheap. Short, readable, and still the reference point for every method that followed. Tim Dettmers et al., "QLoRA: Efficient Finetuning of Quantized LLMs" (2023). Introduces NF4 quantization and shows how to fine-tune a 65-billion-parameter model on one GPU. Its discussion of evaluation limits is as valuable as its method. Dan Biderman et al., "LoRA Learns Less and Forgets Less" (2024), and Thinking Machines Lab, "LoRA Without Regret" (2025). Read together, these give the clearest current picture of when parameter-efficient fine-tuning matches full fine-tuning and when it falls short. Rafael Rafailov et al., "Direct Preference Optimization: Your Language Model Is Secretly a Reward Model" (2023). The method that put preference tuning within reach of small teams. Elias Frantar et al., "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers" (2022), and Ji Lin et al., "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration" (2023). The two foundational papers on 4-bit quantization of language models. Prateek Yadav et al., "TIES-Merging: Resolving Interference When Merging Models" (2023), and Takuya Akiba et al., "Evolutionary Optimization of Model Merging Recipes" (Sakana AI, 2024). Accessible entry points into model merging, from principled interference reduction to automated recipe search. Decentralized training Arthur Douillard et al., "DiLoCo: Distributed Low-Communication Training of Language Models" (2023). The algorithmic foundation of most current collective pretraining. Bowen Peng, Jeffrey Quesnelle, and Diederik P. Kingma, "DeMo: Decoupled Momentum Optimization" (2024). The method behind Nous Research's DisTrO and Psyche network. Prime Intellect, "INTELLECT-1 Technical Report" (2024), and Joel Lidin et al., "Covenant-72B: Pre-Training a 72B LLM with Trustless Peers Over-the-Internet" (2026). Detailed accounts of what it takes to pretrain across the internet, including utilization figures and failure handling. Openness, licensing, and policy Open Source Initiative, "The Open Source AI Definition 1.0" (2024). The definition and its accompanying FAQ explain the reasoning behind the data-information compromise. Matt White et al., "The Model Openness Framework" (2024). A graded classification of model releases by completeness, useful for thinking beyond a binary of open and closed. Irene Solaiman, "The Gradient of Generative AI Release: Methods and Considerations" (2023). A concise map of release options between fully closed and fully open. National Telecommunications and Information Administration, "Dual-Use Foundation Models with Widely Available Model Weights" (2024). The most thorough government analysis of open-weight risks and benefits to date. Regulation (EU) 2024/1689 (the AI Act), Articles 51 to 55, together with the General-Purpose AI Code of Practice (2025). The primary sources on how the EU treats open-source and systemic-risk models. Safety Sayash Kapoor, Rishi Bommasani, et al., "On the Societal Impact of Open Foundation Models" (2024). Introduces the marginal-risk framework and remains the best starting point for the safety debate. Andy Arditi et al., "Refusal in Language Models Is Mediated by a Single Direction" (2024). A striking demonstration of how shallow refusal training is, and a good example of what open weights make possible for safety research. Xiangyu Qi et al., "Fine-tuning Aligned Language Models Compromises Safety, Even When Users Do Not Intend To!" (2023). Shows how little fine-tuning it takes to undo safety behavior. Ecosystem and data Stella Biderman et al., "Pythia: A Suite for Analyzing Large Language Models Across Training and Scaling" (2023), and Dirk Groeneveld et al., "OLMo: Accelerating the Science of Language Models" (2024). Two exemplars of fully open model development. Guilherme Penedo et al., "The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale" (2024). A model of how to document and justify a pretraining data pipeline. Hugging Face, "State of Open Source on Hugging Face: Spring 2026." The platform's own analysis of downloads, derivatives, and the shift toward Chinese base models. Hashtags: #OpenSourceAI #OpenSourceAIEcosystems #OpenWeightAI #OpenSourceInnovation #CommunityDrivenInnovation #ArtificialIntelligence #MachineLearning #GenerativeAI #LargeLanguageModels #LLM #FoundationModels #ModelWeights #OpenModelDevelopment #AIModelLicensing #OpenSourceLicenses #ApacheLicense #MITLicense #ResponsibleAILicensing #OpenSourceInitiative #OpenSourceAIDefinition #AITransparency #AIReproducibility #AICommunity #CollaborativeAI #DemocratizingAI #HuggingFace #LLaMA #DeepSeek #Qwen #MistralAI #EleutherAI #OLMo #OpenAIModels #ParameterEfficientFineTuning #PEFT #LoRA #QLoRA #ModelFineTuning #ModelQuantization #ModelMerging #ModelDistillation #LocalAI #LocalInference #GGUF #LlamaCpp #Ollama #OpenDatasets #DistributedTraining #DecentralizedAI #AIInfrastructure #AIModelEvaluation #AIModelGovernance #AIPolicy #EUAIAct #AISafety #ResponsibleAI #AIRegulation #AIResearch #OpenScience #AIInnovation #FutureOfAI

Download the Book (PDF): Introduction In 1965 General Electric began building a machine called Hardiman. It was meant to let a sailor lift a 680-kilogram load as if it weighed a few dozen kilograms, and on paper it was a triumph of hydraulics: some thirty powered degrees of freedom, a master-slave arrangement in which the operator's limbs moved an inner frame and powerful actuators moved an outer one in step. In practice the machine weighed roughly as much as the loads it was supposed to carry, and attempts to operate the full body led to violent, uncontrolled motion. The project ended with only a single arm working reliably. Nobody was ever allowed to wear the whole thing under power. The usual reading of Hardiman is that the technology of the 1960s was not ready: motors too weak, computers too slow, batteries non-existent. That reading is true and almost entirely beside the point. Sixty years later we have brushless motors with remarkable torque density, embedded processors that run control loops at tens of kilohertz, lithium cells, carbon-fibre composites and inertial sensors that cost less than a cup of coffee. And yet the problem that defeated Hardiman remains the central problem of the field. The machine did not know what the person wanted, it could not deliver force to the person without fighting them, and it attached to a body that is soft, variable and easily injured. Those are not problems of power. They are problems of coupling. This book is built on a single claim: an exoskeleton is not a robot that happens to be worn, but one half of a coupled mechanical system whose other half is a human being, and every important design decision follows from taking that coupling seriously. The human half cannot be reprogrammed, cannot be redesigned and cannot be pushed beyond tissue tolerances. It changes from morning to afternoon as muscles fatigue and skin sweats. It adapts to the machine even as the machine tries to adapt to it. An engineer who starts from the motor and works outward toward the body will build something impressive on a test bench and disappointing on a person. An engineer who starts from the body and works outward toward the motor has a chance. Why this matters now Exoskeletons have left the laboratory in two very different directions. In rehabilitation, devices such as ReWalk, Ekso, Indego, HAL and Atalante have been cleared by regulators and sit in hundreds of clinics, helping people with spinal cord injury and stroke to stand and walk. In the United States the Food and Drug Administration created a dedicated classification for powered lower-extremity exoskeletons after clearing ReWalk in 2014, and a decade later Medicare began paying for personal exoskeletons for home use. In industry, passive back and shoulder supports from companies such as Laevo, Ottobock and Ekso, and powered lifting aids from firms such as German Bionic, are worn on assembly lines, in warehouses and in airport baggage halls. The automotive manufacturers were early adopters; logistics firms followed. Both worlds have learned the same hard lessons. Rehabilitation devices that looked transformative in demonstration videos walk at speeds a third or less of an unimpaired adult's, and the research evidence on their long-term benefit is thinner than their marketing implies. Industrial devices that reduced back-muscle activity by a third in laboratory trials have been quietly returned to storage cupboards because workers found them hot, awkward or simply in the way. Meanwhile, a series of careful laboratory experiments has shown that a well-tuned exoskeleton can genuinely reduce the metabolic cost of walking by a fifth or more, and that the tuning matters more than the hardware. The gap between those findings is the subject of this book. What the book covers The description on the cover names three things: myoelectric control, the translation of human intent into motor torque, and lightweight carbon-fibre frames for industrial lifting and spinal cord injury rehabilitation. Those are the right three things, and they map naturally onto the three places where human and machine meet. The first meeting point is informational: the machine must estimate what the person is trying to do. The second is energetic: the machine must deliver torque at the right moment in the right amount, through actuators whose own dynamics either help or hinder. The third is structural: force must pass from a rigid frame into a soft body through cuffs and straps, and the frame itself must be strong enough to carry it without being so heavy that it costs more than it gives. The chapters follow that logic. The first sets up the coupled-system view and the vocabulary the rest of the book uses: active and passive devices, rigid exoskeletons and soft exosuits, rehabilitation and augmentation, and the idea of transparency. The second and third deal with the electrical activity of muscle: how surface electromyography is generated, recorded and corrupted, and how it is turned into an estimate of intent through proportional control, pattern recognition, musculoskeletal modelling and, increasingly, learned models. The fourth follows intent through to torque, examining the actuators, the low-level control laws and the high-level assistance strategies, including the human-in-the-loop optimisation methods that have done more than any other recent idea to make exoskeletons actually help. The fifth chapter is about the physical interface between machine and skin, which is the most neglected and possibly the most important subject in the field. The sixth is about frames: why carbon-fibre composites dominate the high end, what they are bad at, and how an engineer designs a composite structure that can be adjusted, survive a fall and attach to metal joints without failing at the bond line. The seventh and eighth chapters take the two applications named on the cover, industrial lifting and spinal cord injury rehabilitation, and examine what the evidence shows, what the devices actually do and where they fall short. The ninth deals with safety, standards and validation: how one shows that a machine strapped to a paralysed person will not break their tibia, and how one shows that a back support actually prevents injury rather than merely reducing a number on an electromyography trace. How to read it The intended reader is an intelligent person who wants to understand how these machines work and why they are hard to build: an engineering student considering the field, a clinician deciding whether to invest in a device, an occupational-health manager evaluating a pilot, an investor reading a pitch deck, or a practising roboticist coming from industrial automation. No equations are required. Where a mechanism matters, it is explained in words, with real numbers where real numbers exist. Where a claim rests on a particular study, the study is named in the text and listed in the notes, so the reader can check it. The book does not cover upper-limb prosthetics except where myoelectric control methods were developed for prostheses and later borrowed by exoskeletons, which is often. It does not cover brain-computer interfaces in depth, although they appear where they bear on intent detection. It does not cover military load-carriage exoskeletons beyond their role in the field's history, because the evidence base there is small and much of it unpublished. And it treats soft exosuits as part of the same design space as rigid exoskeletons, because the coupling problems are the same even when the solutions differ. One last framing point. The phrase "rehabilitation and augmentation" suggests two separate markets. In engineering terms they are a single continuum, distinguished mainly by how much of the work the human can still do. A person with a complete thoracic spinal cord injury contributes almost no lower-limb torque; the machine must do nearly everything, and intent must be read from somewhere other than the paralysed muscles. A warehouse worker contributes nearly all of the torque; the machine offers a fraction and must stay out of the way the rest of the time. A person recovering from stroke sits somewhere in the middle, and the machine must assist without doing so much that the nervous system stops trying. Where on that continuum a device sits determines almost everything about how it should be designed. Holding that continuum in mind is the most useful single habit a reader can bring to what follows. CHAPTER 1 Two Bodies, One Mechanism An exoskeleton is a structure worn outside the body that acts in parallel with the body's own joints. That definition, simple as it is, already contains the central engineering fact of the field. A machine in parallel with a joint shares the load with that joint: whatever torque the exoskeleton supplies at the knee, the person's own muscles do not have to supply, provided the two are aligned and acting at the same moment. A machine in series would be different. A prosthetic leg replaces a missing limb and carries the full load; an exoskeleton sits alongside a limb that is still there, and its job is to add to or subtract from what that limb is already doing. Everything difficult about exoskeleton engineering follows from the word "parallel". The parallel coupling and what it implies Consider a knee exoskeleton worn during walking. The human knee flexes to around sixty degrees during swing and extends nearly straight at heel strike. The exoskeleton's knee joint, with its own axis, its own motor and its own frame, is strapped to the thigh and shank. If the two axes coincide perfectly and the straps are perfectly stiff, the exoskeleton's angle equals the human's angle at every instant, and torque from the motor adds cleanly to the torque from the quadriceps and hamstrings. Neither condition ever holds. The human knee is not a hinge; its instantaneous centre of rotation moves several millimetres as the femoral condyles roll and slide on the tibial plateau, and the shank rotates axially by several degrees over the range of flexion. The straps sit on muscle, fat and skin, which compress and shear under load. So the two "joints" are actually coupled through a compliant, lossy, nonlinear spring made of human tissue. When the motor applies torque, some of it reaches the skeleton and some of it is absorbed in deforming tissue or pushing the cuffs up and down the limb. When the person moves, the exoskeleton follows only after the tissue spring has been loaded. This matters in three ways. First, it limits how much torque can usefully be delivered: beyond a certain point, extra torque goes into pressure and shear on the skin rather than into the joint, and the person experiences pain rather than assistance. Second, it limits bandwidth: the tissue spring and the mass of the frame form a resonant system, and if the controller tries to act faster than that system can respond, it will oscillate. Third, it creates parasitic forces: if the exoskeleton's axis is a few centimetres away from the human's, flexing the knee drags the cuffs along the limb, producing forces that do nothing useful and may be uncomfortable or damaging. Chapter 5 deals with these interface problems in detail. For now, the point is conceptual. There is no such thing as "the exoskeleton's performance" independent of the person wearing it. There is only the performance of the coupled pair. A second implication of parallel coupling is that the human remains in charge, or at least must feel as though they are. In a series device such as a prosthetic ankle, the user adapts to whatever the device does because there is no alternative. In a parallel device, the user's own muscles can always fight the machine, and they will if the machine's timing is wrong. Early lower-limb exoskeletons with fixed trajectories, which played back a recorded walking pattern regardless of what the person was doing, worked acceptably for people with complete paralysis because those users had no voluntary muscle activity to conflict with the playback. The same approach is unbearable for an able-bodied person, who experiences it as being dragged around by a stubborn partner. The more capable the wearer, the more the exoskeleton must follow rather than lead. This leads to the single most useful design concept in the field: transparency. An exoskeleton is transparent when, with its assistance switched off or set to zero, the wearer cannot tell it is there except for its mass. Perfect transparency is impossible because the frame has mass and inertia, the transmission has friction and the joints may be slightly misaligned. But the degree to which a device approaches transparency determines how well it can do everything else. A device that resists motion when it should be neutral will add metabolic cost before it subtracts any. Collins, Wiggin and Sawicki's well-known unpowered ankle exoskeleton, published in Nature in 2015, reduced the metabolic cost of walking by about seven per cent with nothing but a spring and a clever clutch, and a large part of its success came from being light and nearly transparent outside the brief window in which the spring engaged. A taxonomy that actually helps Exoskeletons are usually classified along several axes at once, and the resulting labels can obscure more than they clarify. Four distinctions are genuinely useful for engineering purposes. The first is between active and passive devices. An active exoskeleton has actuators, usually electric motors, that inject net positive energy into the human-machine system. A passive exoskeleton has only springs, dampers, counterweights or clutches; it can store energy and return it, redirect it from one phase of motion to another, or transfer load from one body region to another, but it cannot add energy. Most industrial back and shoulder supports are passive. They work by storing energy as the wearer bends forward or raises their arms and returning it as the wearer straightens or holds the arms aloft, and they shift some of the load from the lumbar muscles or shoulder muscles to the thighs or pelvis. A middle category, often called quasi-passive, uses small motors or solenoids to engage clutches or adjust spring stiffness without supplying the main work. Collins's unpowered ankle device is quasi-passive in spirit, though its clutch was mechanical. The second distinction is between rigid exoskeletons and soft exosuits. A rigid exoskeleton has a frame, usually of aluminium, titanium or carbon-fibre composite, with mechanical joints that parallel the body's joints. It can carry compressive loads, transfer weight to the ground and support a person who cannot support themselves. A soft exosuit, a concept developed most extensively by Conor Walsh's group at Harvard's Wyss Institute, uses textiles and cables anchored to the body; motors pull on Bowden cables to create tension across a joint. An exosuit cannot bear compressive load, so it cannot hold a paralysed person upright, but it adds very little inertia and has no joints to misalign. In effect it uses the human skeleton as its frame. The choice between the two is a choice about who carries compressive loads: the machine or the person. The third distinction is about which joints are spanned. Single-joint devices, such as an ankle exoskeleton or a hip exoskeleton, are much easier to design, fit and control than full lower-body devices, and most of the strongest evidence for metabolic benefit comes from single-joint designs. Full lower-body devices, spanning hips and knees and sometimes ankles, are necessary for people who cannot walk at all. Upper-body industrial devices span the shoulder; back devices span the hip and lumbar spine. The fourth and most important distinction is the one the introduction called the continuum of contribution. At one end is a user who contributes essentially no torque at the assisted joints: a person with a complete thoracic spinal cord injury in a powered lower-body exoskeleton. At the other end is a user who contributes almost all of the torque and wants only a little help: a healthy soldier carrying a heavy pack, or a warehouse worker lifting boxes. Between them sits a large population of partially impaired users, including people after stroke, people with incomplete spinal cord injury, people with multiple sclerosis or cerebral palsy, and older adults with weakness. Where a device sits on this continuum dictates how it should read intent, how much torque it needs, how it should handle balance and how it should fail. At the high-contribution end, the device must be light and transparent because any mass or resistance cancels the small benefit it can offer. It reads intent from the motion itself, from joint angles, gait phase and interaction forces, because the motion is a faithful expression of what the user wants. At the low-contribution end, mass matters less because the user is not carrying the device with their own muscles; the device carries itself and the user. But intent cannot be read from the motion, because there is no voluntary motion. It must come from residual signals such as trunk lean, crutch loading, buttons on a wrist controller or, in some devices, electromyography from muscles that still work or partly work. In the middle of the continuum, the device must do the hardest thing of all: give just enough help, at just the right moment, that the user can achieve what they intend without becoming passive. Rehabilitation clinicians call the failure mode "slacking": when the machine does too much, the nervous system learns to let it. A short history told as a sequence of coupling failures The history of exoskeletons is sometimes told as a march of better hardware. It is more instructive told as a sequence of discoveries about coupling. Hardiman, built by General Electric between 1965 and 1971 under contracts with the US Army and Navy, failed because it treated the human as a source of position commands and the machine as a force amplifier that should replicate those positions with enormous gain. Any small error in the human's command was amplified into large, fast motion of a very heavy structure, and the coupling between the inner and outer frames provided no natural damping. The lesson, though it took decades to absorb, was that high-gain amplification of human motion is unstable unless the machine is light, the transmission is stiff and the control loop is very fast. In parallel, researchers in Yugoslavia under Miomir Vukobratović at the Mihajlo Pupin Institute were building powered orthoses for paraplegic patients in the late 1960s and early 1970s. Their work introduced the zero-moment point concept for analysing dynamic balance, an idea that later shaped humanoid robotics. Their devices were pneumatically driven and tethered, and they demonstrated that a paralysed person could be moved through a walking pattern by a machine. They also demonstrated how hard it was to make that walking stable without the person's own balance reflexes. The modern era began around 2000, when the US Defense Advanced Research Projects Agency funded a programme on exoskeletons for human performance augmentation. The Berkeley Lower Extremity Exoskeleton, BLEEX, developed by Homayoon Kazerooni's group and first publicly demonstrated in 2004, carried a backpack load through a frame to the ground, so that the wearer felt little of the pack's weight. Its control approach, which its designers called sensitivity amplification, deliberately avoided placing many sensors on the human; instead it measured the machine's own state and tried to make the machine move in whatever direction the human pushed it, with as little resistance as possible. This was transparency pursued as an explicit goal. BLEEX also exposed the cost of carrying a powered frame: its hydraulic power unit and structure were heavy, and the metabolic benefit to the wearer was not clearly established. At about the same time, Yoshiyuki Sankai at the University of Tsukuba was developing HAL, the Hybrid Assistive Limb. HAL's distinctive feature was that it read intent from surface electromyography: electrodes on the skin over the thigh muscles detected the electrical activity that precedes muscle contraction, and the device supplied torque in proportion. Sankai founded the company Cyberdyne in 2004 to commercialise HAL, and the medical version was eventually approved in Japan for certain neuromuscular diseases and cleared by the FDA for use in spinal cord injury rehabilitation in clinical settings. HAL represents the purest commercial form of the idea at the heart of this book's second and third chapters: that the electrical signal of muscle is the most direct available readout of human intent. The rehabilitation exoskeletons that reached market in the 2010s took a different and more conservative approach. ReWalk, developed by Amit Goffer in Israel after a car accident left him tetraplegic, was cleared by the FDA in 2014 for personal and clinical use by people with spinal cord injury at certain levels. Ekso Bionics, a spin-out from Kazerooni's lab, and Indego, developed at Vanderbilt University and commercialised by Parker Hannifin, followed. These devices do not read electromyography. They detect intent from trunk tilt and weight shift, measured by inertial sensors, and from user buttons; they then play back stepping trajectories. That approach is robust and safe because it does not depend on noisy biological signals, but it produces slow, deliberate walking with crutches and it places a heavy cognitive and upper-body load on the user. Finally, from about 2014 onward, a series of laboratory studies changed the field's understanding of what exoskeletons could do for able-bodied people. Luke Mooney, Elliott Rouse and Hugh Herr at MIT showed in 2014 that an autonomous ankle exoskeleton could reduce the metabolic cost of walking with and without a load. Collins, Wiggin and Sawicki showed in 2015 that an unpowered device could do it. And in 2017, Juanjuan Zhang and colleagues in Collins's lab at Carnegie Mellon showed that by optimising the assistance profile for each individual, while the person walked, an ankle exoskeleton could reduce metabolic cost by about a quarter relative to wearing the same device with zero torque. That result, published in Science, made a point no hardware improvement could have made: the coupling between person and machine is individual, and a controller that adapts to the individual can extract far more benefit than one that does not. What follows from the coupled view Taking the coupled view seriously has practical consequences that recur throughout this book. It means the human must be modelled, at least implicitly, as part of the plant to be controlled. The human's own dynamics, including muscle activation delays, reflexes, tissue compliance and adaptation, enter every stability calculation. A controller that is stable on a test bench with a dummy leg may be unstable on a person, or vice versa, because the person can stiffen or relax. It means that intent detection is not an optional add-on but the first stage of the control loop. Whatever torque the machine supplies must be timed to what the person is trying to do. The earlier the machine can know, the less lag it introduces and the more naturally it can assist. Electromyography is attractive precisely because it precedes motion; mechanical signals such as joint angle are robust precisely because they reflect what has actually happened. Choosing between them, or combining them, is the subject of Chapters 2 and 3. It means that actuators should be chosen for how they feel to the person, not just for their torque and speed. A highly geared motor with a large reduction ratio can produce enormous torque from a small package, but it is hard to back-drive: the person feels its reflected inertia and friction when they try to move it. A motor with a low ratio is easier to back-drive but needs more current for the same torque. Series elasticity and torque sensing can make a stiff actuator feel compliant. These trade-offs, explored in Chapter 4, cannot be resolved without asking how the actuator feels from the human side of the coupling. It means that the interface between frame and body is as important as the frame itself. A brilliant controller is useless if the cuff slides down the leg or raises a pressure ulcer. Chapter 5 is devoted to that interface. It means that weight is not just weight. Mass placed on the distal leg costs far more metabolic energy than the same mass at the waist, because it must be accelerated and decelerated with every step. Raymond Browning and colleagues demonstrated this in 2007 by adding masses to different segments of the legs of walking subjects; the more distal the load, the greater the metabolic penalty per kilogram, with loads at the feet costing far more than loads carried near the body's centre of mass. Carbon-fibre frames are attractive not because they are fashionable but because every gram removed from the shank or foot pays back several times over. Chapter 6 examines how those frames are designed. And it means that evaluation must be done on people doing real tasks, not on machines in isolation. A back-support exoskeleton that reduces erector spinae electromyography by a third while a person repeatedly lifts a box in a laboratory may increase load elsewhere, change lifting technique, impede walking between lifts, or be abandoned within a week. A rehabilitation exoskeleton that allows a person to walk ten metres in a clinic may never be used at home. Chapters 7, 8 and 9 take up those questions of evidence. The rest of the book proceeds through the coupling from information to energy to structure, and then out into the two applications where these machines are actually used. The organising question at every stage is the same: what does this design choice look like from the human side? CHAPTER 2 Reading the Muscle Every voluntary movement begins as a pattern of electrical activity. Motor neurons in the spinal cord fire, action potentials travel down their axons, and at each neuromuscular junction a small packet of acetylcholine triggers an electrical wave that sweeps along the muscle fibres. That wave, the muscle fibre action potential, causes calcium release inside the fibre, and calcium allows the contractile proteins to generate force. The electrical event comes first; the force follows tens of milliseconds later. Surface electromyography, usually abbreviated EMG or sEMG, records a faint echo of those electrical events through the skin. For an exoskeleton designer it offers something no mechanical sensor can: a window onto what the muscle is about to do, before it has done it. This chapter is about the signal itself. It explains where it comes from, why it looks the way it does, how it is recorded, and above all how it is corrupted. The following chapter deals with what to do with it. The division is deliberate. Many failures of myoelectric control are not failures of the algorithm but failures to respect the physics and physiology of the measurement. Where the signal comes from The functional unit of muscle activation is the motor unit: a single motor neuron and all the muscle fibres it innervates. In small muscles controlling fine movements, a motor unit may contain a few dozen fibres; in large leg muscles such as the vastus lateralis or gastrocnemius, a single motor unit can contain many hundreds or more than a thousand fibres scattered through a region of the muscle. When the motor neuron fires, every fibre in the unit fires together, so each motor unit produces a characteristic compound electrical waveform called the motor unit action potential. The nervous system grades force in two ways. It recruits more motor units, generally from small to large, a regularity known as Henneman's size principle; and it increases the firing rate of units already recruited, from a few pulses per second near threshold to several tens per second at high force. The electrical signal at the skin is the sum of all the motor unit action potentials from all active units, each filtered by the tissue between the fibres and the electrode. Because many units fire asynchronously, the sum looks like noise: a zero-mean signal whose amplitude grows with the number and rate of active units. That noise-like character is not a defect of measurement. It is the nature of the signal, and it is why EMG is usually described statistically rather than by its instantaneous value. The useful information in surface EMG for control purposes lies mostly in its amplitude envelope, the slowly varying magnitude of the noise-like carrier. That envelope rises roughly with muscle force, though the relationship is neither linear nor stable, and it leads force by the electromechanical delay. The frequency content also carries information: as a muscle fatigues, conduction velocity along the fibres falls and the spectrum shifts toward lower frequencies, a well-studied phenomenon used in ergonomics to detect fatigue. Surface EMG energy lies mostly between about 20 and 450 hertz, with the bulk of it below 200 hertz. That is why the common recommendation, reflected in guidelines such as those produced by the European SENIAM project around 2000 and in the standard textbooks by Merletti and Farina, is to band-pass filter between roughly 10 to 20 hertz at the low end and 450 to 500 hertz at the high end, and to sample at 1 kilohertz or more. The lower cut-off removes motion artefact, which is concentrated at low frequencies; the upper cut-off removes high-frequency noise and respects the sampling theorem. Amplitudes are small. A strong voluntary contraction might produce a few millivolts peak-to-peak at the skin surface; a weak contraction, or a partly paralysed muscle, may produce tens of microvolts. That places EMG in a regime where the noise floor of the amplifier, the impedance of the skin-electrode contact and the electrical environment all matter. Electrodes, amplifiers and placement Practical surface EMG uses a bipolar arrangement: two electrodes placed along the direction of the muscle fibres over the muscle belly, typically with centres around 20 millimetres apart, and a reference electrode on electrically quiet tissue such as a bony prominence. A differential amplifier subtracts the signals from the two recording electrodes. Interference that appears equally at both, most importantly mains hum at 50 or 60 hertz coupled capacitively from the environment, cancels; the local muscle signal, which differs between the two sites because the action potential passes under them at different times, survives. The quality of this cancellation is expressed as the common-mode rejection ratio, and good biopotential amplifiers achieve 100 decibels or better. The electrode placement affects everything. Placing electrodes over the innervation zone, where motor end plates cluster and action potentials propagate in both directions, reduces the differential signal and makes it unstable. Placing them near the tendon reduces amplitude. Placing them near the edge of a muscle increases crosstalk, the pickup of signals from neighbouring muscles. In the thigh, for example, signals from vastus lateralis and rectus femoris overlap substantially; in the calf, soleus and gastrocnemius contaminate each other. Crosstalk is not merely a nuisance in exoskeleton control. If a knee exoskeleton is meant to assist extension in proportion to quadriceps activity but the electrode also picks up hamstring activity, it may push the knee into extension precisely when the person is trying to flex it. Laboratory systems traditionally used wet silver/silver-chloride gel electrodes, which give low and stable impedance but dry out over hours and are impractical for daily donning. Wearable systems increasingly use dry electrodes of stainless steel, conductive polymers or textile-integrated conductors. Dry electrodes have higher and more variable impedance, particularly in the first minutes before sweat moistens the contact, so they are almost always paired with active electronics at the electrode site: a small buffer amplifier that converts the high-impedance source into a low-impedance signal before it travels down a cable. Active electrodes dramatically reduce cable motion artefact and pickup. An exoskeleton adds two problems that a laboratory EMG setup does not face. The first is the cuff. The very places where an engineer would like to put electrodes, over the thigh and calf muscle bellies, are also where the exoskeleton cuffs press on the limb. Pressure from a cuff changes the electrode contact, can shift the electrode relative to the muscle, and, when the cuff transmits a pulse of force as the motor engages, can produce artefacts synchronised with the device's own action. This is a feedback path from the actuator to the sensor, and if it is not designed out, it can produce self-sustaining oscillation. The second problem is electrical: brushless motors driven by pulse-width-modulated inverters produce strong electromagnetic fields at the switching frequency and its harmonics, and their currents flow in cables that run past the electrodes. Careful shielding, cable routing, filtering and, in some designs, synchronising EMG sampling to the inverter switching cycle are needed. How the signal is corrupted It is worth listing the main sources of corruption explicitly, because each demands a different remedy and because the list explains why myoelectric control that works on the first afternoon often fails on the second day. Motion artefact arises from relative movement between electrode and skin, and from deformation of the skin itself, which changes the electrochemical potential at the electrode interface. It is mostly below 20 hertz and can be very large compared with the EMG. High-pass filtering helps, but large artefacts saturate the amplifier and corrupt everything in the window. Mechanical design, including stable electrode mounting, light cable strain relief and avoiding placement directly under cuff edges, matters more than filtering. Power-line interference arises from capacitive coupling to mains wiring and equipment. Differential amplification and driven-right-leg circuits suppress it; notch filters at 50 or 60 hertz remove what remains but also remove real EMG energy at that frequency. Electrode shift is a slow, insidious problem. If an electrode moves by even a centimetre relative to the muscle, perhaps because the user donned the device slightly differently, or because the cuff rotated during use, the amplitude and spectral content of the recorded signal change. A pattern-recognition classifier trained with the electrode in one place may misclassify badly with it in another. Studies of prosthetic myoelectric control in the 2000s, notably by the groups around Kevin Englehart and Bernard Hudgins at the University of New Brunswick, documented how shifts of around a centimetre degraded classification and how training across several positions improved robustness. Changes in skin impedance occur with sweat, temperature and time. Sweat generally lowers impedance and increases signal amplitude, so a system calibrated on cool dry skin will see larger signals after twenty minutes of exertion and may over-assist. In an industrial setting, where a worker may wear an exoskeleton for a full shift in a warm warehouse, this drift is a serious obstacle. Muscle fatigue alters both amplitude and spectrum. During sustained or repeated submaximal contractions, the amplitude of surface EMG for a given force typically rises as additional motor units are recruited to compensate for fatiguing ones, and the spectrum shifts downward. An amplitude-based controller will interpret the rising signal as a request for more force, and may well provide it. Whether that is the right response is a design question: arguably, a fatigued worker should receive more help, but the controller is not actually measuring fatigue; it is misreading it as intent. Crosstalk, discussed above, depends on electrode placement, subcutaneous fat thickness and muscle geometry. Thicker fat layers act as a spatial low-pass filter, blurring signals from separate muscles together and reducing amplitude. This has an uncomfortable consequence: myoelectric control tends to work less well on people with more subcutaneous tissue, and calibration procedures developed on lean young laboratory volunteers may not transfer. Finally, the electromechanical delay, the interval between the onset of electrical activity and the onset of measurable force, varies across muscles and conditions. Reported values in the literature range from around ten milliseconds to around a hundred, depending on the muscle, the measurement method and whether tendons are slack. This delay is a gift to the control engineer, because it means the EMG signal leads the mechanical action and provides some time to compute a response. But the gift is variable and partly consumed by the processing needed to extract a clean amplitude estimate. The special case of the injured nervous system For able-bodied users, EMG is a reasonable if noisy proxy for intended joint torque. For the populations that rehabilitation exoskeletons serve, the relationship can be very different, and an engineer who forgets this will design the wrong device. After a complete spinal cord injury, muscles below the level of injury receive no voluntary drive. There is no intent signal there to read. They may, however, produce involuntary activity: spasms, clonus and reflex responses to stretch, all mediated by spinal circuits that have lost descending control. An EMG-driven controller placed on paralysed thigh muscles would therefore detect activity that does not reflect intent and might respond to a spasm by driving the knee. This is one reason the major exoskeletons for complete spinal cord injury do not use lower-limb EMG; they read intent from trunk motion instead. After an incomplete injury, some descending pathways survive. Voluntary EMG may be present but weak, abnormally timed or mixed with spasticity. Muscles that should be silent may co-contract with their antagonists. The amplitude may bear little resemblance to the force produced, because the muscle itself has atrophied and its fibre composition has changed. HAL's use in this population is interesting precisely because Cyberdyne's approach treats faint residual EMG as a signal to be amplified: the idea, sometimes described by its proponents as interactive biofeedback, is that by responding to the person's own attempts to move, the device closes a loop between intention and movement that may promote neural recovery. Whether that mechanism operates as proposed is still debated, and the clinical evidence is discussed in Chapter 8. But the engineering point stands: in this population, the meaning of the EMG signal changes over weeks as recovery or deterioration occurs, and any controller must be recalibrated often. After stroke, the problems are different again. Weakness on one side is often accompanied by abnormal synergies, in which muscles that should be independently controlled activate together, and by spasticity. An EMG-driven device that assists in proportion to, say, biceps activity may simply amplify an abnormal flexor pattern. Here the designer must decide whether the device should reinforce what the person is doing or shape it toward something more normal, a decision that belongs to clinicians as much as engineers. Beyond the bipolar pair Two developments have expanded what surface EMG can deliver, and both are now reaching wearable devices. High-density surface EMG replaces a single bipolar pair with a grid of dozens or hundreds of small electrodes. The spatial pattern of activity across the grid contains far more information than a single channel. Most importantly, using blind source separation techniques developed over the past two decades, notably by Dario Farina, Roberto Merletti and their collaborators, it is possible to decompose a high-density recording into the firing trains of individual motor units. That changes the nature of the signal from a noisy amplitude envelope into something close to the neural drive itself: the actual spike trains being sent from the spinal cord to the muscle. Motor unit decomposition has been demonstrated in real time in laboratory conditions, and it is beginning to appear in research prosthetics and in studies of residual activity in paralysed muscles. Its practical obstacles for exoskeletons are the same as for any EMG, magnified: grids must stay in fixed contact with the skin over the muscle while the limb moves and the cuffs press, and the decomposition is sensitive to shifts. The second development is multimodal sensing. Because EMG alone is fragile, many modern systems combine it with other signals. Inertial measurement units on the thigh, shank and foot give segment orientations and accelerations. Joint encoders on the exoskeleton give joint angles. Force-sensitive insoles give ground contact and centre-of-pressure information. Force or torque sensors in the cuffs measure the interaction between person and machine directly. Ultrasound imaging of muscle, explored in research settings, measures changes in muscle thickness and pennation that relate to contraction. Mechanomyography, the low-frequency vibration of contracting muscle picked up by an accelerometer on the skin, provides a mechanical correlate of activation that is immune to electrical interference. In practice, fusion of EMG with mechanical sensors outperforms either alone, because the failure modes are different: EMG fails with electrode shift and sweat; mechanical sensors fail to anticipate. What a designer should take from this The surface EMG signal is attractive because it leads motion and reflects intent more directly than any mechanical measurement. It is difficult because it is small, noisy, non-stationary and dependent on details of placement and physiology that change between sessions and between people. The engineering response has three parts. First, design the hardware to protect the signal: active electrodes, stable mounting that is mechanically decoupled from cuff forces, short and shielded cables, careful separation from motor drives, and placement that respects anatomy and avoids innervation zones and cuff edges. Second, design the processing to tolerate the inevitable corruption: robust feature extraction, normalisation that tracks slow drift, and decision logic that can detect when the signal has become untrustworthy and fall back to a safer mode. Third, and most important, design the control architecture so that EMG is used where its strengths matter and other signals carry the load where they do not. Using EMG to anticipate the onset of a movement, or to scale the magnitude of assistance, plays to its strengths. Using it as the sole determinant of the direction and timing of large torques, in a device worn by someone whose EMG may be distorted by injury, does not. The next chapter takes up the question of how the cleaned signal is turned into a command: how a stream of microvolts becomes an estimate of what the person wants to do, and how that estimate becomes a number that a motor controller can act on. CHAPTER 3 From Signal to Intent An exoskeleton controller is usually described in three layers. The high level decides what the person is trying to do: walk, climb stairs, sit down, lift, hold still. The middle level decides what the device should do about it: what torque, at what time, following what profile. The low level makes the motor actually produce that torque. This chapter is about the high level and the parts of the middle level that depend on biological signals. It asks a deceptively simple question: given a stream of electromyographic and mechanical measurements, how do we produce an estimate of the person's intent that is accurate enough, fast enough and robust enough to drive a motor strapped to their body? There is no single answer. There are four broad families of method, each with a distinct idea of what "intent" means, and they differ in what they require from the signal, how they fail and what they cost to calibrate. Understanding the differences is more useful than mastering any one technique. Four ideas of intent The oldest and simplest idea treats intent as a quantity: how hard the person is trying. In proportional myoelectric control, the amplitude envelope of one or more EMG channels is scaled directly into a torque or force command. The envelope is usually obtained by full-wave rectification followed by a low-pass filter, or by computing a moving root-mean-square over a short window. The scaling is calibrated by asking the person to perform a maximal or reference contraction and normalising to it. If the person activates the soleus to push off at the end of stance, the ankle exoskeleton adds plantarflexion torque in proportion. Proportional control has a long and productive history in research exoskeletons. Daniel Ferris and colleagues at the University of Michigan built a series of pneumatically actuated ankle-foot orthoses in the mid-2000s whose artificial muscles were driven in proportion to the wearer's soleus EMG. Their 2006 paper in Gait & Posture described an improved version of this device; subsequent work by Gregory Sawicki and Ferris used it to study how people adapt to powered assistance, and found that wearers reduced their own soleus activity substantially, by roughly a sixth to a quarter in their study of incline walking, as they learned to let the machine do part of the work. That adaptation is itself an important finding: in a proportional myoelectric system, the human's response to assistance changes the very signal that drives the assistance. The loop closes through the nervous system. The appeal of proportional control is its directness. It does not need to know what task the person is doing. It does not need a model of walking. It responds within the latency of the envelope filter, and because EMG leads force, it can supply torque roughly in phase with the person's own muscles. Its weaknesses are the weaknesses of the signal: it inherits every drift, artefact and crosstalk problem described in the previous chapter, it cannot easily distinguish a contraction intended to move the joint from a co-contraction intended to stiffen it, and it requires careful normalisation that must be repeated as conditions change. The second idea treats intent as a category: which movement the person is trying to make. Pattern-recognition control extracts a set of features from short windows of multichannel EMG and uses a classifier to assign each window to one of a small number of classes. The approach was developed for upper-limb prostheses, where a user with a below-elbow amputation needs to select among hand open, hand close, wrist rotation and so on using residual forearm muscles. The foundational paper by Bernard Hudgins, Philip Parker and Robert Scott in 1993 introduced a compact set of time-domain features: mean absolute value, zero crossings, slope sign changes and waveform length. Those features, often called the Hudgins set, remain the workhorse of the field more than thirty years later. Kevin Englehart and Hudgins's 2003 paper in IEEE Transactions on Biomedical Engineering showed how to run such a classifier continuously in real time, using overlapping windows and a majority vote over successive decisions to smooth the output, and demonstrated high accuracy with a simple linear discriminant classifier. Commercial pattern-recognition systems for prostheses, such as the one Coapt brought to market in the early 2010s, descend directly from this work. In lower-limb exoskeletons, pattern recognition is used less for selecting among joint movements and more for recognising locomotion modes: level walking, stair ascent, stair descent, ramp ascent, ramp descent, sitting, standing and transitions between them. A device that assists level walking with one torque profile needs a different profile on stairs, and it needs to know about the change before the first step onto the stair, not after it. Here EMG is typically fused with mechanical signals from joint encoders, inertial sensors and load cells, and the most informative moments for classification turn out to be specific gait events such as heel strike and toe-off, when the body's preparation for the next step is visible in both muscle activity and mechanics. Research by Levi Hargrove, Aaron Young and colleagues on powered prostheses in the 2010s showed that such fusion reduces mode-recognition errors substantially compared with mechanical sensors alone, and similar architectures have been carried over to exoskeletons. The weakness of the categorical view is that the world is continuous. A person does not walk in one of seven modes; they walk on a slope of four degrees, then a slope of six, then turn while stepping over a cable. Classifiers trained on discrete laboratory tasks can produce confident wrong answers when the real task falls between categories, and a wrong mode often means a wrong torque profile with the wrong sign. For safety, pattern-recognition systems need a rejection option, so that a low-confidence decision results in no change of mode or in a reduction of assistance. Erik Scheme, Hudgins and Englehart described confidence-based rejection for prosthetic control in 2013, and the principle applies with greater force to exoskeletons, where a misclassification moves a person's body rather than a prosthetic hand. The third idea treats intent as the person's own joint torque: what the muscles are actually trying to produce, estimated through a model of the musculoskeletal system. In an EMG-driven musculoskeletal model, each recorded EMG channel is processed into a muscle activation signal through a model of activation dynamics, which captures the delay and smoothing between neural excitation and force-producing state. The activation drives a Hill-type muscle model, named after A. V. Hill's classic work on muscle mechanics, in which force depends on activation, on the length of the muscle fibres relative to their optimal length and on their velocity of shortening or lengthening. The fibre length and velocity are computed from joint angles through a geometric model of where each muscle attaches and how its tendon wraps around bones. The muscle forces are multiplied by moment arms and summed to give the net joint torque. David Lloyd and Thor Besier published an influential version of this approach for the knee in 2003. Calibration adjusts parameters such as optimal fibre length, tendon slack length and maximum isometric force for each subject so that the model's predicted torques match torques measured by inverse dynamics in a motion laboratory. Once calibrated, the model can predict joint torque from EMG and joint angle alone, without force plates or motion capture. Massimo Sartori, Dario Farina, Guillaume Durandau and collaborators have since developed real-time versions that run within the timing constraints of a wearable device; Durandau, Farina and Sartori's 2018 paper in IEEE Transactions on Biomedical Engineering demonstrated robust real-time estimation during walking, and the same group has used model-based estimates to drive ankle exoskeletons across walking conditions. The model-based approach has two profound advantages. It respects physics: a model that knows a muscle cannot produce force when it is very short, or that a biarticular muscle acts on two joints at once, will not make physically impossible predictions when the inputs drift into unfamiliar territory. And it generalises across tasks, because the same muscles and the same mechanics underlie walking, stair climbing and lifting. Its cost is calibration: building and tuning a subject-specific model has traditionally required a motion laboratory, an expert operator and hours of work. Reducing that burden, through scaling from anthropometry, through automated calibration on a few simple tasks, or through hybrid methods that learn some parameters from data, is an active research front. The fourth and newest idea treats intent as whatever a learned model can predict from the available signals. In data-driven estimation, a neural network or other machine-learning model is trained to map sensor data directly to a target quantity: joint torque, gait phase, locomotion mode or desired assistance. The most striking recent example is the 2024 Nature paper by Dean Molinaro, Aaron Young and colleagues at Georgia Tech. They trained a temporal convolutional network on data from a large and varied set of cyclic and non-cyclic tasks, from level walking and stairs to irregular everyday movements, to estimate the wearer's own biological hip moment from sensors on a hip exoskeleton, and then commanded assistance as a fraction of that estimated moment. The result was a single controller that assisted across a wide range of tasks without needing to classify them first. The idea of using the estimated biological joint moment as the universal input for assistance has spread rapidly; by 2026 the same group had published a roadmap for end-to-end task-agnostic exoskeleton control in Nature Machine Intelligence. The appeal of the data-driven approach is flexibility: given enough data, a learned model can capture relationships that no hand-crafted model would include. Its weaknesses mirror those of all machine learning applied to safety-critical systems. It needs large, diverse training data, ideally from people similar to the target users; it can fail in unpredictable ways on inputs unlike its training set; and it is difficult to certify, because its behaviour cannot be fully described in advance. Interestingly, several of the most successful data-driven exoskeleton controllers do not use EMG at all, relying instead on joint encoders and inertial sensors, which are more stable across sessions. Where EMG has been added, as in work by Keaton Scherpereel and colleagues in the same group on combining EMG with instrumented insoles, it has improved estimates in tasks where mechanics alone are ambiguous. Comparing the families Table 1 summarises the four families along the dimensions that matter most for a designer: what they estimate, what they need to calibrate, how they typically fail and where they fit on the continuum of user contribution described in Chapter 1. Table 1. Main approaches to estimating user intent for exoskeleton control. Approach What it estimates Calibration burden Typical failure Best suited to Proportional myoelectric Effort level from EMG amplitude Short; repeated each session Drift with sweat, fatigue, electrode shift Single-joint assistance in users with intact EMG Pattern recognition Discrete movement or locomotion mode Moderate; retraining after shifts Confident misclassification between classes Mode switching for stairs, ramps, sit-stand EMG-driven musculoskeletal model Continuous joint torque from muscle forces High; subject-specific parameters Errors from model mismatch and poor EMG Research and clinical devices needing physiological plausibility Data-driven learned model Joint moment, phase or assistance directly High up front; low per user if model generalises Unpredictable errors outside training data Multi-task augmentation with mechanical sensors None of these is strictly superior. Commercial rehabilitation devices for complete paralysis use none of them in the lower limb, relying instead on trunk lean and user-commanded steps. Commercial industrial back exoskeletons that are powered generally use mechanical sensors to detect bending and lifting, not EMG. The myoelectric approaches have been most successful where users have healthy or partly healthy muscles and the device spans a single joint. The latency budget Whatever method is used, it must operate within a latency budget. If assistance arrives too late, the person has already done the work and the device merely adds a delayed push that may interfere with the next phase of movement. If the estimate is smoothed to reduce noise, it becomes delayed; if it is computed over a long window to improve accuracy, it becomes delayed. The prosthetics literature offers the clearest quantitative guidance. Todd Farrell and Richard Weir's 2007 study of controller delay for myoelectric prostheses found that users' performance on manipulation tasks degraded once delays exceeded a threshold, and they recommended keeping the delay between roughly 100 and 125 milliseconds, with faster delays preferable for more skilled users. This is not a universal constant: it depends on the task and the joint. In walking, a single stride lasts about one second and the push-off phase at the ankle lasts a fraction of that, perhaps 150 to 200 milliseconds; a delay of 100 milliseconds in delivering ankle torque would shift assistance well into the wrong part of the cycle. For gait, designers therefore rarely rely on raw EMG timing alone. They use EMG or mechanical signals to estimate gait phase, a continuous variable running from heel strike to the next heel strike, and then deliver torque according to a profile indexed by phase. Because gait is periodic, the controller can predict where in the cycle the person will be a fraction of a second hence, which compensates for processing delay. The electromechanical delay described in Chapter 2 offers some headroom. If EMG leads force by around 50 milliseconds, and processing takes 30, the torque command can still arrive before or with the muscle's own force. But the headroom is uncertain and partly consumed by the actuator's response time, which is the subject of the next chapter. Combining estimates and deciding what to do with them In practice, robust exoskeletons fuse several estimates. A typical architecture might use joint encoders and inertial sensors to estimate gait phase and locomotion mode, use EMG to scale the magnitude of assistance or to anticipate transitions, and use interaction-force sensors in the cuffs to detect when the person is fighting the device. A supervisory layer monitors the consistency of the estimates: if the EMG-derived estimate says the person is pushing hard but the interaction force says they are being dragged, something is wrong, and the safe response is to reduce assistance. There is a deeper question beneath all this: once the device knows what the person wants, what should it do? Supplying a fixed fraction of the estimated biological torque, as several of the approaches above imply, is intuitive but not necessarily optimal. The human nervous system will adapt to the assistance; the person may reduce their own effort so much that the total torque stays the same and the benefit vanishes into relaxation, or they may change their gait in ways that make the original estimate wrong. Chapter 4 describes how the field has learned to answer this question empirically, by letting the controller search for the assistance that actually produces the desired outcome in the person wearing it. For rehabilitation devices, the question takes a specific form. If the goal is recovery, assistance should be "as needed": enough to allow successful practice, but no more, so that the patient's own neural drive remains engaged. Assist-as-needed control uses the error between the desired and actual movement, or an estimate of the patient's capacity, to scale assistance downward as performance improves. Here intent detection serves a double role: it provides the timing for assistance and also a measure of how much the person can do on their own. What intent detection cannot do It is worth ending this chapter with the limits. No intent detection method reads the mind. Each estimates a proxy, whether effort, category, torque or phase, from signals that are themselves proxies for neural activity. Each makes assumptions about what the person is likely to do that can be violated. The safest designs acknowledge this by bounding what the device can do in response to any single estimate, by preferring smooth changes over abrupt ones, and by making the person's ability to override the device simple and reliable. For users at the low-contribution end of the continuum, intent detection is often reduced to explicit commands: a button on a crutch handle, a wrist-worn remote, a deliberate weight shift. That may sound primitive compared with myoelectric decoding, but it reflects a defensible judgement. When the machine is doing nearly all the work and a mistake could cause a fall, an unambiguous command is worth more than an elegant inference. The sophistication of intent detection should rise with the user's capacity to recover from its errors. CHAPTER 4 From Intent to Torque Once a controller has decided what torque it wants at a joint, something must produce that torque and deliver it to the human limb. This is the job of the actuator and its low-level controller, and it is where the abstract idea of transparency from Chapter 1 becomes a concrete set of engineering trade-offs. A motor that can produce the required torque is easy to find. A motor that can produce it in a package light enough to wear, quickly enough to track a gait profile, quietly enough not to annoy, efficiently enough to run all day on a battery, and gently enough that the wearer does not feel it when it should be idle, is not. This chapter describes the main actuator architectures, the control laws that make them behave as torque sources, and the higher-level strategies that decide how much torque to provide. It ends with the most important idea to emerge from exoskeleton research in the past decade: that the best assistance cannot be calculated in advance, but must be found by searching, with the person in the loop. What the joint demands A sense of the numbers helps. During level walking at a typical speed, the human ankle produces a peak plantarflexion moment of roughly 1.5 newton-metres per kilogram of body mass, so around 110 to 120 newton-metres for a 75-kilogram adult, and a peak positive power during push-off on the order of 2 to 3 watts per kilogram. The knee produces lower peak moments in level walking but much higher ones in stair ascent and in rising from a chair. The hip produces moderate moments over a longer portion of the cycle. These values, documented in standard references such as David Winter's biomechanics textbook, set the scale of the actuation problem, but an exoskeleton rarely needs to supply all of them. Augmentation devices for healthy users typically supply a fraction, perhaps a quarter to a half of the biological peak at one joint. Rehabilitation devices for complete paralysis must supply nearly everything, but they do so at walking speeds far below normal, which reduces the power requirement substantially. Speed matters as much as torque. Joint angular velocities in walking reach several radians per second at the knee during swing. An actuator that can produce high torque only at low speed may be adequate for slow rehabilitation walking but will be dragged by a healthy user. And bandwidth matters: the actuator must change its torque on a time scale of tens of milliseconds to follow a gait profile, which requires a closed-loop torque bandwidth of perhaps ten hertz or more for lower-limb augmentation. The main architectures Electric motors dominate wearable robotics because they are efficient, clean, quiet compared with hydraulics, easy to control and compatible with battery power. But a brushless motor of wearable size produces its best power at speeds of thousands of revolutions per minute and torques of a fraction of a newton-metre. Converting that into tens of newton-metres at a few revolutions per second requires a transmission, and the transmission is where most of the design choices lie. The first approach is high-ratio gearing. A harmonic drive, also called a strain-wave gear, offers ratios of 50:1 to 160:1 in a compact, nearly zero-backlash package, which is why it appears in many industrial robots and in several rehabilitation exoskeletons. The problem is that the reflected inertia of the motor's rotor scales with the square of the gear ratio, and friction in the gear is substantial. At a ratio of 100:1, a rotor with modest inertia feels to the human like a heavy flywheel, and the gear's friction adds a resistance the person feels as stiffness. Such an actuator is poorly back-drivable: the person cannot easily move the joint when the motor is idle. For a paralysed user this hardly matters, because the user is not trying to move the joint alone, and the stiffness can even be welcome. For an augmentation user it is a serious defect. The second approach is series elasticity. Gill Pratt and Matthew Williamson's 1995 paper introducing the series elastic actuator proposed putting a deliberately compliant spring between a geared motor and the load. Measuring the spring's deflection gives a direct and cheap measure of output torque, which can be controlled in closed loop. The spring also filters shocks, protecting the gearbox and the person from impacts, and it stores energy that can be returned. And, counterintuitively, it improves force control: by lowering the stiffness seen by the controller, it allows higher feedback gains without instability. The cost is bandwidth: a soft spring limits how fast the actuator can change its output force, particularly at large amplitudes. Series elastic actuators were used in several of the most influential lower-limb exoskeletons and prostheses of the 2000s and 2010s, including the LOPES gait trainer at the University of Twente, whose joints were driven through Bowden cables into series elastic elements, and in many research ankle and knee devices. The third approach is quasi-direct drive. Inspired by legged robots such as the MIT Cheetah, quasi-direct-drive actuators use a large-diameter, high-torque brushless motor with a low gear ratio, typically under 10:1 and often around 6:1 to 9:1. Reflected inertia and friction are low, so the actuator is highly back-drivable, and torque can be estimated from motor current with reasonable accuracy, avoiding the need for a separate torque sensor. The cost is mass: a motor that produces useful torque with little gearing must be relatively large. Shuangyue Yu, Hao Su and colleagues published a 2020 paper in IEEE/ASME Transactions on Mechatronics describing a quasi-direct-drive hip exoskeleton with high back-drivability and high bandwidth, and the approach has become popular for hip and knee augmentation devices. The fourth approach is remote actuation through cables. Soft exosuits and some rigid devices place the motors at the waist or on the back and transmit force to the ankle or knee through Bowden cables: an inner cable sliding inside a flexible outer sheath. The distal limb then carries only an anchor and a pulley, which minimises the metabolic penalty of distal mass discussed in Chapter 1. The cost is friction in the sheath, which depends on how much the cable bends and therefore varies with posture, and compliance, which reduces bandwidth. Cable-driven designs can only pull, not push, so bidirectional assistance requires two cables or a spring return. Walsh's exosuits at Harvard, including the portable hip exosuit reported by Jinsoo Kim and colleagues in Science in 2019, and the commercial ReStore device derived from that work and cleared by the FDA for stroke rehabilitation, use this architecture. A fifth, older approach uses pneumatic artificial muscles, braided sleeves around an inflatable bladder that contract when pressurised. They have a high power-to-weight ratio and natural compliance, and Ferris's early myoelectric ankle orthoses used them. But they need a source of compressed air, which is awkward for a wearable device, and their force is nonlinear and difficult to control precisely. Hydraulic actuation, the choice of Hardiman and of BLEEX, offers exceptional force density but carries the weight and complexity of pumps, valves and fluid, and is now rare outside a few full-body industrial and military systems. Table 2 compares these architectures on the properties that matter most from the human side of the coupling. Table 2. Actuator architectures for exoskeleton joints. Architecture Typical gear ratio Back-drivability Torque sensing Main drawback Harmonic drive 50:1 to 160:1 Poor Separate sensor needed High reflected inertia and friction Series elastic 20:1 to 100:1 plus spring Good at low frequency Spring deflection Limited large-force bandwidth Quasi-direct drive Below 10:1 Excellent Motor current Larger, heavier motor Bowden cable remote Any, motor at waist Good when slack Load cell on cable Posture-dependent friction, pull only Pneumatic muscle None Inherently compliant Pressure-based estimate Air supply, nonlinear force Source: ranges compiled from published device descriptions cited in the notes; individual designs vary. The choice is not a matter of finding the best actuator but of matching the actuator to the position on the continuum of user contribution. A rehabilitation device for complete paralysis can tolerate high gearing and poor back-drivability in exchange for compactness and holding torque; it may even need a brake to hold the knee locked while standing. An augmentation device for healthy walkers needs excellent back-drivability so that it does not cost more than it gives. Devices for partial impairment sit between and often use series elasticity or quasi-direct drive. Making a motor feel like what you want The low-level controller's job is to make the actuator behave as the higher levels intend. The fundamental decision is what quantity to control. Position control, in which the actuator follows a commanded angle, is natural for industrial robots and for exoskeletons that impose trajectories on paralysed limbs. It is wrong for any user who contributes their own effort, because it fights every deviation the person attempts. The alternative, articulated most clearly by Neville Hogan in a series of three 1985 papers on impedance control, is to control the relationship between motion and force rather than either one alone. An impedance controller makes the actuator behave like a virtual spring and damper, possibly with a moving set point: if the person deviates from the set point, the device pushes back with a force proportional to the deviation and its rate, but it yields. By setting the virtual stiffness high, the controller approximates position control; by setting it to zero, it approximates pure torque control, ideally transparent. Between the extremes lies a continuum of behaviours that can be matched to the user's capacity. Assist-as-needed rehabilitation controllers often take this form: a soft virtual spring pulls the limb toward a desired trajectory, so that a patient who can follow it alone feels little force, while one who deviates feels a corrective push. The dual of impedance control is admittance control, in which the controller measures the force applied by the person and commands a motion in response, as though the device were a virtual mass and damper being pushed. Admittance control suits high-ratio, poorly back-drivable actuators, because the controller can compensate for their friction and inertia by moving them in the direction the person pushes. It requires a good force sensor at the interface and is prone to instability when the person stiffens their limb. For augmentation devices with back-drivable actuators, the most common approach is simply torque control: the high level specifies a desired assistive torque as a function of gait phase or estimated biological moment, and the low level tracks it using motor current, spring deflection or a torque sensor in closed loop. Even here, the coupling to the human enters. The torque the actuator produces is not the torque the person receives: some is lost to the inertia of the frame, some to the compliance of the cuffs. Feedforward compensation for the frame's own gravity and inertia, sometimes called gravity and inertia cancellation, can improve transparency, but it requires accurate models and becomes unstable if overdone. Stability deserves emphasis. A coupled human-exoskeleton system with a stiff controller and soft tissue in the interface can oscillate at frequencies of several hertz to tens of hertz. The person may experience this as a buzzing or chattering. The traditional robotics remedy is passivity: designing the controller so that the device, seen from its interface port, never generates net energy at any frequency. A passive device coupled to a passive environment is guaranteed stable. Humans are not strictly passive, since muscles inject energy, but they are well approximated as passive at the frequencies where control instabilities occur. Passivity-based design therefore offers a principled way to guarantee stability regardless of how the person stiffens or relaxes, at the cost of limiting how aggressively the device can cancel its own inertia. Deciding how much to help Above the low level sits the question of what torque profile to provide. For walking, the most common representation is a torque curve as a function of gait phase, often parameterised by a few numbers: peak torque, timing of the peak, onset time and offset time. Early devices chose these parameters by imitating biological torque curves scaled to a fraction of normal, or by hand-tuning in pilot experiments. The trouble is that the optimal assistance profile is not the biological profile, and it differs between people. Two people of identical size may respond very differently to the same torque, because their muscles, tendons, walking styles and adaptation strategies differ. Some people relax and let the device do the work; others continue to generate their usual torque and walk differently. The metabolic benefit depends on the whole system's response, which cannot be predicted from first principles. The breakthrough came in 2017. Juanjuan Zhang and colleagues in Steven Collins's laboratory, then at Carnegie Mellon University, used a tethered ankle exoskeleton emulator, a test-bed in which powerful motors off the body drive the device through cables, allowing any torque profile to be applied, and searched over four parameters of the assistance profile while participants walked on a treadmill. They measured metabolic rate by respiratory gas analysis and used an evolutionary optimisation algorithm, the covariance matrix adaptation evolution strategy, to update the parameters every few minutes. After an extended optimisation session, participants' metabolic rate when walking with the optimised assistance was reduced by about 24 per cent compared with walking in the device with zero torque. The optimised profiles differed markedly between participants, and when participants received a profile optimised for someone else, the benefit fell. The paper's title in Science, "Human-in-the-loop optimization of exoskeleton assistance during walking", gave its name to a research programme that has since been applied to hip exosuits, knee devices and running. The method's weakness was its dependence on laboratory measurement: respiratory gas analysis is cumbersome, metabolic rate takes minutes to stabilise after each parameter change, and treadmill walking is not natural walking. Patrick Slade, Mykel Kochenderfer, Scott Delp and Collins addressed this directly in a 2022 Nature paper. They built a portable ankle exoskeleton and trained a data-driven model to estimate the metabolic effect of assistance from the device's own sensor data, rather than from gas analysis. They then ran the optimisation while participants walked in the real world, through Stanford's campus and city streets. After a brief period of optimisation, participants walked about 9 per cent faster and expended about 17 per cent less energy per unit distance than when walking in normal shoes. That comparison is against normal shoes, not against wearing the device unpowered, which is the comparison that matters for a real user. Several lessons follow. The first is that assistance should be personalised: the gain from tuning to the individual is as large as the gain from good hardware. The second is that the objective function matters: optimising for metabolic cost produces different profiles from optimising for comfort, for speed or for symmetry of gait. In rehabilitation, where the goal may be gait symmetry or propulsion from the weaker leg, different objectives are needed, and Louis Awad, Walsh and colleagues' 2017 work with exosuits in stroke survivors explicitly targeted improvements in paretic push-off. The third is that the person adapts during the optimisation, so the optimiser is chasing a moving target; the protocols that work best give participants time to learn each new setting. The fourth is that human-in-the-loop optimisation is a way of discovering what the person's nervous system wants, which is the deepest form of intent detection. Batteries, heat and the energy budget Every actuator choice has an energy consequence. A wearable device runs on a battery whose mass the wearer must carry; if the battery is on the back, its metabolic cost is low per kilogram but not zero. Motors convert electrical energy into mechanical work with efficiencies that depend strongly on operating point: brushless motors are most efficient at moderate torques and high speeds, and least efficient at high torques and low speeds, which is unfortunately where many exoskeleton joints spend much of their time. Holding a static torque, for example locking a knee during stance or supporting a load in an industrial lift, consumes electrical power continuously while doing no mechanical work, and the losses appear as heat in the motor windings. Heat is a frequently underestimated constraint. A motor strapped to a person must keep its external surfaces cool enough not to burn skin, and standards for medical devices set limits on the temperature of parts that contact the body. Designers therefore oversize motors to keep them cool, add heat sinks or airflow, or use clutches and brakes to hold static loads without current. Quasi-passive designs, which use small motors only to engage springs or clutches, achieve their efficiency precisely by avoiding the cost of holding torque with current. The net energy budget of an assistive device is therefore more complicated than "motor power in, assistance out". It includes the metabolic cost of carrying the device's mass, distributed according to where it sits on the body; the electrical energy drawn from the battery; the heat generated and dissipated; and the change in the wearer's own metabolic expenditure. A device is only worthwhile for augmentation if the last term outweighs the first, and the evidence of the past decade, from Mooney and Herr's autonomous ankle device onward, shows that with careful design and individual tuning it can. Bringing it together Translating human intent into motor torque is a chain: biological signals are estimated into an intent, the intent is mapped into a torque command through an assistance strategy, and the command is realised by an actuator whose own dynamics shape what the person actually feels. Errors at any link propagate. A perfect intent estimate is useless if the actuator cannot respond in time; a superb actuator is wasted if the assistance profile is wrong for the person. The practical lesson of the past decade is that the last link, the person, is both the most important and the most variable. Exoskeletons that assume a standard human perform worse than those that learn the individual human, and the methods for learning, by optimisation, adaptation and estimation, are now as much part of exoskeleton engineering as gears and motors. CHAPTER 5 Where Machine Meets Skin Every newton-metre an exoskeleton produces must pass into the human skeleton through skin, fat and muscle. There is no other route. The bones that the device is trying to move, support or unload sit beneath several centimetres of soft tissue that was never designed to carry concentrated external loads, that varies enormously between people and between parts of the same limb, and that can be injured by pressure sustained for less time than a working shift. The physical interface, the cuffs, straps, shells, pads and harnesses that connect frame to body, is therefore not an accessory. It is a structural and physiological component whose performance limits everything upstream of it. This chapter treats the interface as an engineering problem in three parts: how force is transmitted through soft tissue and what that costs; how the kinematics of the device must accommodate the kinematics of the body; and how fit, adjustment and donning determine whether a well-engineered device is actually used. Force through soft tissue When a cuff on the thigh pushes on the limb to assist knee extension, the force does not arrive at the femur directly. It compresses the skin and subcutaneous fat, then the muscle, then reaches bone. Each layer is soft, viscoelastic and nonlinear: soft at small deformations and stiffening as it compresses. The result is that the cuff must move some distance relative to the bone before it transmits much force, and the force that does pass rises steeply as the tissue stiffens. From an engineering perspective this creates two problems. The first is loss. Work done compressing tissue is partly stored and partly dissipated, and the portion dissipated is lost to the assistance. Matthew Yandell, Karl Zelik and colleagues, in a 2017 study published in the Journal of NeuroEngineering and Rehabilitation, measured how much of the mechanical work delivered by an exosuit actually reached the body, and found that compliance in the interface and the suit absorbed a substantial share; their analysis showed that interface dynamics alter not only how much assistance arrives but when it arrives, since storage and release of energy in soft components shift the timing of force delivery. The lesson generalises to rigid exoskeletons: the stiffer the interface, the more efficiently force reaches the skeleton, but the more concentrated the pressure on the tissue. The second problem is injury. Sustained pressure on soft tissue obstructs blood flow through the capillaries. A long tradition of research into pressure injuries, dating back to Eugene Landis's measurements of capillary pressure in 1930, established that external pressures exceeding a few tens of millimetres of mercury can restrict capillary perfusion, and that tissue deprived of perfusion for long enough dies. In practice the threshold for injury depends strongly on duration, shear, temperature, moisture and the person's health. Healthy people avoid pressure injuries by shifting position in response to discomfort. People with spinal cord injury often cannot feel the discomfort and cannot easily shift, and their skin is more vulnerable because of changes in circulation and tissue composition below the level of injury. Skin abrasions and pressure marks are among the most commonly reported adverse events in exoskeleton studies of people with spinal cord injury, and many study protocols require skin checks before and after each session. Shear is often more damaging than normal pressure. When a cuff slides along the limb under load, or when the limb moves inside the cuff because the device's joint is misaligned, the skin is dragged relative to underlying tissue. Shear distorts capillaries, tears the junction between skin layers and accelerates breakdown. A cuff that is snug enough to prevent sliding raises normal pressure; a cuff loose enough to avoid pressure allows sliding and shear. The interface designer works within that tension. Several design responses follow. Distributing load over a larger area lowers peak pressure. Wide cuffs, contoured shells moulded to the limb's shape and compliant liners all help. Placing cuffs over regions with more favourable tissue, such as muscle bellies rather than bony prominences, reduces concentration. Aligning the direction of interaction forces with the limb's surface normal, rather than having them act tangentially, reduces shear. And reducing the forces that need to be transmitted in the first place, by aligning joints well and minimising parasitic loads, helps more than any padding. In rehabilitation devices for complete paralysis, a further consideration applies. The device must support body weight through the frame into the ground when the person stands, which means some cuffs and the foot plate carry large loads continuously. The foot plate in particular must transmit body weight without producing pressure points on an insensate foot. Rehabilitation exoskeletons therefore often use the user's own shoe inside a foot plate or footbed, and clinicians monitor the feet closely. Kinematic compatibility The second part of the interface problem is geometric. The human joint and the exoskeleton joint must move together. If their axes do not coincide, then as the joint flexes, the distance between the cuff on the thigh and the cuff on the shank, measured along the limb, changes. Either the cuffs slide on the skin, or they stay put and the device forces the limb into an unnatural path, compressing or stretching the joint. The magnitude of this effect is not small. Suppose an exoskeleton knee axis sits two centimetres anterior to the anatomical axis. As the knee flexes through ninety degrees, each cuff tends to move along the limb by a distance comparable to that offset. In practice the error is worse, because the human knee does not rotate about a fixed axis. Its instantaneous centre of rotation moves along a curved path as it flexes, so even a perfectly placed fixed hinge is misaligned for most of the range. The ankle and hip present their own problems: the ankle's axes are oblique and differ between the talocrural and subtalar joints, and the hip is a ball-and-socket joint deep within soft tissue whose centre cannot be seen or easily palpated. The traditional response was careful fitting: adjust link lengths and joint positions so that the device's hinge lies over the anatomical joint at the posture where loads are highest. That works tolerably for a single user in a single posture, but not across the range of motion. André Schiele and Frans van der Helm, in a 2006 paper in IEEE Transactions on Neural Systems and Rehabilitation Engineering, set out the problem systematically and argued for a different approach: add passive degrees of freedom to the device, so that it can accommodate misalignment rather than impose its own geometry. A knee exoskeleton might add a sliding joint along the thigh, or a second rotational axis, allowing the cuffs to remain stationary on the skin while the device's linkage reconfigures. Such self-aligning mechanisms decouple the transmission of assistive torque from the exact location of the human joint axis. The idea has been implemented in many forms. Some knee designs use a four-bar linkage or a cam-and-follower to approximate the moving centre of rotation of the natural knee. Others add prismatic joints in the thigh and shank segments. Some hip designs use remote-centre mechanisms that rotate about a point inside the body without any hardware at that point. The cost of extra degrees of freedom is mass, complexity, and the risk that unconstrained motions allow the device to slip into postures where it cannot transmit torque. A good self-aligning design constrains exactly the motions it should and leaves free exactly the motions it should not interfere with. Soft exosuits sidestep much of this problem because they have no mechanical joints; their cables pass across joints and act on whatever axis the body uses. But they introduce their own kinematic issue: as the joint moves, the cable path changes, and so does its moment arm. A cable anchored at the heel and the calf has a moment arm about the ankle that varies with ankle angle, so the same cable tension produces different torques at different points in the gait cycle. Exosuit controllers must account for this. Anchoring soft suits and harnesses Rigid exoskeletons can at least push against a frame that holds its shape. Soft exosuits and the harnesses of industrial devices face a subtler interface problem: anchoring. A textile suit that pulls on a cable crossing the ankle must react that tension somewhere higher on the body, typically at a waist belt and through straps running down the thigh. Every time the motor pulls, the belt is pulled downward and the thigh straps are pulled along the leg. If the anchors slip, part of the motor's travel is spent taking up slack rather than producing tension, the timing of assistance shifts, and the suit gradually migrates out of position over the course of a walk. Exosuit designers therefore pay close attention to where the body offers natural purchase. The iliac crests of the pelvis provide a ledge above which a well-fitted waist belt can resist downward pull. The conical shape of the thigh, wider at the top, resists upward migration of a thigh wrap better than downward. The heel and the shoe provide a firm distal anchor. A good exosuit routes its load paths between these features so that tension is reacted by bone-adjacent structures rather than by sliding fabric. The same logic applies to industrial harnesses. A shoulder-support exoskeleton must react the upward force it applies to the arms, and the reaction must go somewhere. In most designs it passes down a frame along the back to a hip belt, so that the load is borne by the pelvis rather than by the shoulders. If the hip belt is loose or sits too high, the reaction shifts onto the shoulder straps, and the device presses down on the very shoulders it is meant to relieve. Back-support devices have the mirror-image problem: the extensor moment they create must be reacted at the chest and thighs, and the chest pad becomes the most frequent site of complaint because the sternum and ribs offer little soft tissue and are sensitive to pressure, particularly for women, for whom chest pad geometry designed on male volunteers can be poorly suited. A worked example shows the scale of the problem. Suppose a back-support device supplies an extensor moment of 30 newton-metres about the hip during a stooped lift, reacted by a chest pad located 40 centimetres above the hip axis. The chest pad must then push on the chest with a force of about 75 newtons, roughly the weight of a 7.5-kilogram mass. Spread over a pad of 100 square centimetres, that is an average pressure of 7.5 kilopascals, or about 56 millimetres of mercury, already above the range at which capillary flow begins to be compromised if sustained. Brief exposure during a lift is tolerable; holding a stooped posture for minutes is not. The same arithmetic explains why designers push chest pads as high as possible, to lengthen the lever arm, and make them as large as practical, to spread the load. It also shows why the assistive moment a back-support device can provide comfortably is fundamentally limited by the interface, not by the spring or motor. Measuring the interaction Because the interface is where things go wrong, measuring it directly is valuable. Force sensors built into cuffs, or arrays of thin-film pressure sensors between cuff and skin, can report the interaction forces in real time. Those measurements serve three purposes. They provide feedback for the controller. Admittance control, described in Chapter 4, relies on measured interaction force; even impedance-controlled devices use interaction force to detect when the person is resisting. A sharp rise in interaction force where none is expected suggests misalignment, a conflict between the device and the person's intent, or an obstruction. They provide a safety check. Limits on interaction force or pressure can be built into the controller, so that the device reduces or removes assistance before tissue is injured. They provide design data. Measured pressure maps over long sessions reveal where cuffs concentrate load, where shear occurs and how the distribution changes with fit. Many interface improvements in commercial devices have come from such data rather than from theory. Sensors at the interface face harsh conditions: sweat, temperature changes, repeated compression and bending. Thin-film force-sensitive resistors drift and creep; capacitive sensors are more stable but sensitive to moisture. Load cells in the cuff attachment rather than at the skin are more robust but measure only resultant forces, not their distribution. As with EMG, the measurement is a proxy, and the controller must treat it with appropriate scepticism. Fit, adjustment and donning The third part of the interface problem is practical, and it decides whether devices are used. People differ in segment lengths, limb circumferences, joint ranges and the distribution of soft tissue. An exoskeleton must adjust to fit a useful fraction of the population, and every adjustment adds mass and a potential point of failure. Rehabilitation exoskeletons typically offer adjustable thigh and shank lengths, adjustable hip width and a range of cuff sizes. Clinical devices that are shared among many patients must be readjusted for each, which takes therapist time; studies of clinical implementation identify setup and adjustment time as a significant burden. Personal devices may be fitted once by a trained clinician and left. Industrial exoskeletons face a different version of the problem. A device purchased for a production line may be worn by different workers on different shifts, so adjustments must be quick and intuitive. Research on deployment, including a 2026 study in PLOS ONE that timed participants setting up and taking down four occupational exoskeletons, has found that the number of procedural steps in assembly and donning, more than the number of parts, predicts how long setup takes and how often it fails. A device that takes several minutes and several attempts to put on will be left on the hook. Donning matters even more for users with paralysis. A person with complete paraplegia must be able to put on the device from a wheelchair, ideally without assistance, and must be able to remove it safely. Personal-use exoskeletons are designed around this sequence: the device is laid out or positioned, the person transfers into it or straps it on segment by segment while seated, then stands with crutches. The time and effort involved, often reported as several minutes even for experienced users, form part of the daily cost of using the device. Thermal comfort completes the picture. Cuffs and harnesses cover skin that would otherwise dissipate heat by sweating; padding traps moisture; the motors and batteries add heat. In industrial settings, particularly in warm warehouses or outdoor work, heat is among the most commonly cited reasons for discomfort and rejection. Ventilated liners, breathable fabrics and minimising contact area all help, but they trade against load distribution. The interface as a design driver The physical interface is often designed last, after the frame, actuators and controller have been settled. That ordering is backwards. The interface determines how much force can be transmitted without injury, which sets the useful actuator size. It determines how much misalignment can be tolerated, which constrains the kinematic design of the frame. It determines what the controller can measure and how quickly force reaches the body, which affects stability and bandwidth. And it determines comfort, donning time and acceptability, which decide whether the device is used. A designer who starts from the interface asks: what forces can this person's tissue accept, at which locations, for how long? What range of body sizes must the device fit? How will it be put on and taken off, by whom? The answers then flow outward to the frame and actuators. That is the coupled-system view applied to hardware, and it is the subject of the next chapter, which turns to the frame itself and to the composite materials that make lightweight frames possible. CHAPTER 6 Frames That Weigh Almost Nothing The frame of a rigid exoskeleton has three jobs. It carries loads: the actuator's reaction torque, the weight of the device and, in rehabilitation devices, the weight of the person. It holds geometry: it keeps the joints where they are meant to be, so that the kinematic compatibility worked out in the previous chapter is not undone by bending. And it must do both while adding as little mass as possible, because every gram is carried by somebody, and grams on the distal limb cost the wearer far more than grams at the waist. Those three jobs pull in different directions. A strong, stiff frame is easy to make if mass is no object. A light frame is easy to make if it need not be stiff. The engineering problem is to achieve enough stiffness and strength at minimum mass, in a structure that can be adjusted to fit different people, survives being dropped, attaches reliably to motors and joints, and can be manufactured at a cost the market will bear. Carbon-fibre-reinforced polymer composites have become the material of choice at the high end of this problem, but they are not a universal answer, and understanding why requires some understanding of what they are. Why stiffness, not strength, usually governs Exoskeleton frames rarely fail by breaking. They fail, in the sense of not doing their job, by bending too much. Consider a thigh segment forty centimetres long transmitting a knee torque of fifty newton-metres from the joint to the thigh cuff. The structure acts like a beam, and its deflection depends on its bending stiffness, the product of the material's elastic modulus and the cross-section's second moment of area. If the segment deflects by a few millimetres under load, the knee joint moves relative to the cuff, the alignment carefully designed into the device is lost, and some of the actuator's motion goes into bending the frame rather than moving the limb. Worse, a flexible frame forms a spring in series with the actuator and the tissue, lowering the resonant frequency of the coupled system and limiting control bandwidth. For this reason, frame design typically begins with a stiffness requirement. How much deflection or rotation is acceptable at the joint under the peak design load? From that requirement and the available envelope, the designer chooses a material and section. Strength is then checked to ensure that stresses under peak and fatigue loads are acceptable, and usually they are, with margin. When stiffness governs, the relevant material property is specific stiffness: elastic modulus divided by density. Here an interesting fact emerges. The common structural metals, steel, aluminium alloys and titanium alloys, have almost identical specific stiffness. Steel is roughly three times as stiff as aluminium and roughly three times as dense; titanium sits between. For a given stiffness requirement and a free choice of section, a steel, aluminium or titanium member of the same shape will weigh about the same. The differences between metals show up in strength, in how thin a wall can be before it buckles, in fatigue, in corrosion and in cost, but not in basic specific stiffness. Carbon fibre breaks that pattern. A carbon fibre of the widely used standard-modulus type has a tensile modulus around 230 gigapascals and a density around 1.8 grams per cubic centimetre, so its specific stiffness is about five times that of the metals. Embedded in an epoxy matrix at a typical fibre volume fraction of around sixty per cent, a unidirectional laminate retains much of that advantage along the fibre direction. That is the fundamental reason carbon composites dominate where mass matters most: in aircraft, racing bicycles, prosthetic feet and the frames of high-end exoskeletons. Table 3 compares representative properties. Table 3. Representative properties of candidate frame materials. Material Density (g/cm3) Elastic modulus (GPa) Tensile strength (MPa) Specific stiffness (GPa per g/cm3) Steel, 4130 normalised 7.85 205 about 670 26 Aluminium, 7075-T6 2.81 72 about 570 26 Titanium, Ti-6Al-4V annealed 4.43 114 about 950 26 CFRP, unidirectional, fibre direction about 1.55 about 130 about 2,000 to 2,500 about 85 CFRP, quasi-isotropic laminate about 1.55 about 45 to 55 about 600 to 800 about 30 to 35 Source: typical handbook values for the metal grades; representative values for standard-modulus carbon/epoxy laminates at roughly 60 per cent fibre volume. Actual values depend on grade, processing and layup. The last row of the table holds the most important lesson. A carbon composite laminate with fibres arranged equally in all directions, a quasi-isotropic layup, has specific stiffness only modestly better than the metals. The large advantage exists only along the fibres. Carbon composites are therefore not simply a better metal. They reward a designer who knows exactly which way the loads run and punish one who does not. A simple comparison makes the point concrete. Suppose a shank segment is to be a round tube 30 centimetres long with an outer diameter of 25 millimetres, and the design requirement is a given bending stiffness. An aluminium tube meeting that requirement with a wall of, say, 1.5 millimetres weighs a little over 90 grams. A steel tube of the same stiffness would need a wall about a third as thick, roughly half a millimetre, and would weigh about the same; but such a thin steel wall would dent and buckle locally under the slightest knock, so in practice the steel tube would be made thicker and heavier than stiffness alone requires. A carbon tube with most of its plies running along its axis, achieving perhaps 100 gigapascals of axial modulus, could meet the same requirement with a wall of around a millimetre and weigh roughly 40 per cent of the aluminium tube. The saving of some 50 grams sounds trivial, but it sits on the shank, where every gram is accelerated forward and stopped again with every step, and it is multiplied by every segment of the frame. Over a full lower-limb device the difference between a well-designed composite frame and an aluminium one can amount to a kilogram or more, much of it in the most metabolically expensive locations. Designing with anisotropy A composite laminate is built from plies, thin layers in which the fibres run in a single direction or are woven in two. The designer chooses the orientation and number of plies to match the load paths. In a tubular frame member loaded primarily in bending, the largest stresses run along the length of the tube, so most plies run at zero degrees, parallel to its axis. Torsion, which twists the tube, produces shear stresses best carried by plies at plus and minus forty-five degrees. Plies at ninety degrees, wrapped around the circumference, resist crushing and help the tube hold its shape where clamps or fittings bear on it. A typical exoskeleton tube layup combines all three, weighted toward zero-degree plies for bending stiffness. Getting this wrong is easy. A frame member that sees unexpected torsion, perhaps because the actuator's reaction torque passes through it or because the user twists the limb, will be much weaker and more flexible than its bending stiffness suggests if it lacks forty-five-degree plies. A member loaded by a strap pulling perpendicular to its surface may delaminate, the plies separating from one another, because the matrix and the interfaces between plies are much weaker than the fibres. Composites are strong in the plane of the laminate and weak through its thickness. The best load paths for exoskeletons are therefore those that keep the composite loaded in plane: tubes in bending and torsion, shells carrying membrane forces, plates in in-plane shear. Load paths that require the composite to carry concentrated forces through its thickness, such as bolts loading a thin laminate, straps pulling perpendicular to a shell, or clamps squeezing a tube, require local reinforcement and careful detailing. Joints, inserts and the bond line An exoskeleton frame is not a single part. It connects to actuators, joint bearings, adjustment mechanisms, cuffs and the battery housing, and most of those components are metal. The connection between composite and metal is where composite exoskeleton frames most often fail. There are three main ways to make the connection. Mechanical fastening drills holes through the laminate and bolts it to a metal fitting. It is simple and inspectable, but the holes cut fibres, and the bolts bear on the laminate through its thickness, producing stress concentrations; laminates must be locally thickened and the layup chosen to resist bearing failure. Adhesive bonding glues the composite into or onto a metal fitting, typically a sleeve into which a tube is bonded, or a lug onto which a shell is bonded. It distributes load over a large area and avoids drilling, but the bond's strength depends heavily on surface preparation, adhesive selection, cure and the geometry of the joint ends, where peel stresses concentrate. Bonded joints are also hard to inspect. Co-cured inserts mould metal fittings directly into the composite during manufacture, giving the best load transfer but making the part impossible to disassemble and complicating manufacturing. Galvanic corrosion is a hazard specific to carbon. Carbon fibre is electrically conductive and electrochemically noble. When it contacts aluminium in the presence of moisture, especially salty moisture such as sweat, the aluminium corrodes. An exoskeleton worn against the skin, sweated into for hours a day, is a nearly ideal environment for galvanic corrosion at carbon-aluminium joints. Standard practice is to isolate the carbon from aluminium with a layer of glass-fibre composite or a non-conductive adhesive film, to use titanium or stainless steel fittings, which are galvanically more compatible with carbon, or to seal the joint against moisture. A designer who bonds an unprotected aluminium fitting to a carbon tube has built a corrosion cell. Adjustability adds further difficulty. Rehabilitation and industrial exoskeletons must fit different people, so segment lengths and widths must be adjustable. The most common approach in metal frames, telescoping tubes clamped at the desired length, works poorly with composites, because clamping crushes the tube through its thickness and the clamped zone is a stress concentration. Solutions include metal sleeves bonded to the composite tube that take the clamp, discrete length positions with pins through reinforced holes, or adjustment mechanisms entirely in metal fittings at the ends of fixed-length composite members. Some manufacturers avoid adjustment altogether for personal devices and produce segments in several fixed sizes. Damage, fatigue and inspection Metals usually fail gradually and visibly: they yield, bend, crack and grow cracks slowly enough to be detected. Composites behave differently. Under fatigue loading in tension along the fibres, carbon composites are excellent, far more durable than aluminium, which has no true fatigue limit. Under compression, and especially after impact damage, they are less forgiving. Impact is the critical case for exoskeletons. A device dropped on a clinic floor, struck by a wheelchair or bumped against a doorframe can suffer internal delamination without visible surface damage. Aerospace engineers call this barely visible impact damage, and they design for it by assuming that such damage exists and ensuring the structure retains adequate strength with it. An exoskeleton frame that relies on the compressive strength of a laminate, for example a shank segment supporting body weight, must be designed with the same assumption. In practice, this means lower allowable compressive stresses, protective covers or bumpers in vulnerable regions, and inspection procedures. Fatigue requirements are substantial. A person walking a few thousand steps a day loads each frame segment once per step, accumulating a million cycles in a year or two. An industrial back support worn for a shift may see hundreds of bending cycles per hour. The frame must survive these cycles with margin, at the loads actually experienced, including the occasional overload when the person stumbles. Composite fatigue design draws on data and methods developed for aircraft and wind turbine blades, but exoskeleton-specific loading spectra, measured on real users over long periods, are still scarce. For medical devices, fatigue and static strength tests are part of the evidence submitted to regulators, typically following test protocols derived from orthotic and prosthetic standards. Industrial devices have historically had less rigorous requirements, though that is changing as standards bodies, discussed in Chapter 9, develop test methods. Manufacturing routes How a composite part is made determines its properties, cost and design freedom. Roll-wrapped and filament-wound tubes, made by wrapping prepreg sheets or impregnated fibre tows around a mandrel, are the cheapest way to make high-quality composite tubes and are produced in large volumes for bicycles, sporting goods and drones. An exoskeleton designer can often buy standard tubes and bond them to custom fittings, which keeps costs low and quality high. Prepreg moulding, in which sheets of fibre pre-impregnated with resin are laid into a mould and cured under heat and pressure in an autoclave or, increasingly, in out-of-autoclave processes using vacuum alone, produces complex shells and lugs of excellent quality. It is labour-intensive and suits low volumes, which is the reality for most medical exoskeletons. Resin transfer moulding, in which dry fibre preforms are placed in a closed mould and resin is injected, suits higher volumes and gives good surface finish on both sides of a part. Compression moulding of chopped-fibre or short-fibre composites, and injection moulding of fibre-filled thermoplastics, give lower properties than continuous-fibre laminates but much lower cost and cycle time. They suit covers, housings and lightly loaded parts. Additive manufacturing has opened a newer path. Printers that lay continuous carbon fibre within a thermoplastic matrix can produce custom parts directly from digital models, and conventional polymer printers can make moulds and fixtures cheaply. This matters for personalisation: a cuff or shell shaped from a 3D scan of a particular person's limb can be printed or moulded quickly. Carbon-fibre ankle-foot orthoses, used widely in clinical orthotics for decades, are increasingly custom-fabricated from scans, and exoskeleton interface components are following. Where carbon belongs, and where it does not Carbon composites earn their place where mass matters most and loads are well understood. In a lower-limb exoskeleton, that means the shank and foot segments, where the metabolic cost of mass is highest and the loading is dominated by bending along the segment. It means long thigh members where stiffness is needed over a long span. In industrial devices, it means the struts that carry load from shoulders or trunk to hips, where the device must be light enough to wear for hours. They earn their place less clearly in parts with complex, multi-directional loading and many attachments, such as hip joint housings and actuator mounts, where machined aluminium or titanium may be lighter once all the reinforcements and inserts a composite would need are included. They are a poor choice for parts that must be frequently adjusted by clamping, or that will be exposed to sharp impacts without protection. Many successful devices are hybrids: machined aluminium or titanium joint housings and actuator mounts, connected by carbon tubes or shells. The art lies in the transitions. A well-designed hybrid uses each material where its properties fit the loads, isolates the carbon from aluminium, transfers load through bonded sleeves of sufficient length, and places adjustment in the metal parts. Cost remains a real constraint. Carbon fibre is more expensive than aluminium per kilogram, composite parts require more labour and more process control, and quality assurance is harder. For an industrial back support sold in competition with passive spring devices costing a few thousand euros, carbon may be justified only for the most mass-critical parts. For a rehabilitation exoskeleton priced in tens of thousands, the material cost is a minor share, but certification of a new composite structure adds time and expense. The broader point is that the frame is part of the coupled system. Its mass shapes the metabolic cost of wearing the device, its stiffness shapes control bandwidth and alignment, its adjustability shapes fit and donning, and its durability shapes whether it survives real use. Choosing carbon fibre is not a badge of sophistication. It is a decision that makes sense when it reduces mass where mass costs the wearer most, and when the designer is prepared to handle anisotropy, joints, corrosion, impact and manufacturing with the care those materials demand. CHAPTER 7 Lifting for a Living Low back pain is the single largest cause of years lived with disability worldwide. The Global Burden of Disease collaborators, writing in The Lancet Rheumatology in 2023, estimated that about 619 million people had low back pain in 2020 and projected that the number would rise to around 843 million by 2050, mostly because of population growth and ageing. A large share of that burden falls on people whose work involves repeated lifting, bending and twisting: warehouse pickers, baggage handlers, nurses, construction workers, assembly-line operators. Work-related musculoskeletal disorders are the most common occupational health problem in the European Union and a major source of lost working days in every industrialised economy. Against that background, the idea of an exoskeleton that takes some of the load off the lower back is compelling. If a device can reduce the forces on the lumbar spine during each lift, then over thousands of lifts in a shift and hundreds of thousands in a year, it might prevent injuries. That idea has driven the commercial market for industrial exoskeletons since the mid-2010s. This chapter examines the biomechanics behind it, the devices that have been built, the evidence about what they do, and the gap between laboratory results and working life. The mechanics of a lift When a person bends forward to pick up a box from the floor, the weight of their upper body and the box creates a large moment about the lower lumbar spine, conventionally analysed at the junction of the fifth lumbar vertebra and the sacrum. That moment must be balanced by the back extensor muscles, chiefly the erector spinae, and by passive tissues such as ligaments and the thoracolumbar fascia. The problem is leverage. The erector spinae act on the spine with a moment arm of only about five centimetres, while the upper body and the load act at a horizontal distance of tens of centimetres in a stooped posture. To balance a moment produced by, say, a 15-kilogram box held 40 centimetres in front of the spine plus the weight of the trunk, arms and head, the back muscles must generate forces of several thousand newtons. Those muscle forces press the vertebrae together, so the compressive force on the lumbar discs rises far above the weight being lifted. The US National Institute for Occupational Safety and Health, in the work behind its revised lifting equation published in the early 1990s, adopted a disc compression of 3,400 newtons as a biomechanical criterion above which the risk of injury increases for many workers. The lifting equation's load constant of 23 kilograms is the maximum recommended weight under ideal conditions: close to the body, at waist height, infrequently, without twisting. Real tasks rarely meet those conditions. Lifting from floor level, reaching forward, twisting and lifting repeatedly all reduce the recommended limit. A back-support exoskeleton intervenes by providing an extensor moment about the hip or lumbar spine in parallel with the muscles. If the device supplies some of the extensor moment, the muscles need to supply less, and spinal compression falls correspondingly. The device must anchor somewhere: typically on the chest or shoulders above and on the thighs below, transmitting force around the hip and lower back through a frame or through elastic elements running along the back. The amount of moment a device can usefully provide is limited. A comfortable chest pad and thigh cuffs can transmit perhaps tens of newton-metres before pressure becomes uncomfortable, while the total extensor moment in a heavy stooped lift can be well over a hundred newton-metres. So realistic devices supply a fraction, often reported as somewhere between ten and forty per cent of the muscle demand in laboratory conditions. That fraction is not trivial for cumulative loading over a shift, but it is not a solution to heavy lifting. Passive and active designs Passive back-support exoskeletons store energy in springs or elastic elements as the wearer bends forward, and return it as they straighten. The Laevo, developed in the Netherlands and one of the earliest commercial products, uses a chest pad and thigh pads connected by a frame with spring-loaded hinges at the hips. As the wearer bends, the springs compress and push back against the chest and thighs, creating an extensor moment. Tim Bosch, Michiel de Looze and colleagues tested it in a 2016 study published in Applied Ergonomics: during static forward bending and simulated assembly, back muscle activity fell substantially, and the time participants could sustain a forward-bent holding task roughly tripled. But participants also reported increased discomfort in the chest region, where the pad pressed, and the study involved young adults performing laboratory tasks. Other passive designs include Ottobock's Paexo Back, the suitX backX, now part of Ottobock, and textile-based exosuits such as the HeroWear Apex, developed from Karl Zelik's work at Vanderbilt. The Apex uses elastic bands running along the back and over the buttocks to the thighs, with a switch that lets the wearer engage the bands for lifting and disengage them for walking or sitting. That switch addresses a basic problem with passive back supports: a spring that helps when bending also resists when walking, climbing stairs or sitting, because hip flexion compresses it regardless of purpose. Erik Lamers and Zelik described the design logic and modelling of a dual-mode back-assist exosuit in Wearable Technologies in 2021. Active back-support exoskeletons use motors, usually at the hips, to supply extensor torque. Their advantage is that they can modulate assistance: they supply torque when the person lifts, little or none when the person walks, and they can increase or reduce torque based on detected task demands. German Bionic's Cray X and its successor models, Innophys's pneumatic Muscle Suit in Japan, Hyundai's industrial wearable robots and various research platforms such as the XoTrunk developed at the Italian Institute of Technology fall into this category. Their disadvantages are mass, cost, battery life and complexity. Tommaso Poliero and colleagues compared XoTrunk with the passive Laevo in a 2022 paper in IEEE Robotics and Automation Letters. The active device reduced back muscle activation by more than twice as much as the passive one in their dynamic lifting task, roughly 41 per cent against 16 per cent on one measure, and participants preferred it for dynamic work; but for the static task, participants preferred the passive device. That result illustrates a theme that runs through industrial exoskeleton research: no device is best for all tasks. Passive devices are cheap, light and simple, and they work well for sustained postures. Active devices offer more assistance and adaptability but at higher cost and mass. The right choice depends on the job. Intent detection in active industrial devices is almost always mechanical rather than myoelectric. Hip joint angles from encoders, trunk inclination from inertial sensors and sometimes force sensors detect when the person is bending and when they begin to lift. Industrial EMG faces all the problems described in Chapter 2, magnified by long shifts, heat, sweat and the need for workers to don the device quickly without skin preparation, and the benefit is small when the lift itself can be detected from trunk motion within a fraction of a second. Shoulders and arms Not all industrial exoskeletons support the back. A second large category supports the arms during overhead work: installing components under a car on an assembly line, drilling into ceilings, painting. Holding the arms overhead loads the shoulder muscles, particularly the deltoids and the trapezius, in a sustained way that leads to fatigue and, over years, to shoulder disorders. Passive shoulder exoskeletons, such as the EksoVest and its successor Ekso EVO, Levitate's Airframe, Ottobock's Paexo Shoulder, the suitX shoulderX and Skelex, use springs or gas struts mounted on a frame at the back and hips to support the upper arms when they are raised. They are among the most widely deployed industrial exoskeletons, partly because the support they provide is well matched to a specific posture. Ford worked with Ekso Bionics to develop and pilot the EksoVest in its assembly plants in the late 2010s. The evidence for shoulder devices illustrates both their promise and the gap between laboratory and field. Sander De Bock and colleagues at the Vrije Universiteit Brussel, in a 2020 paper titled "Passive shoulder exoskeletons: more effective in the lab than in the field?", tested two devices on industrial workers. In controlled tasks the devices reduced upper trapezius activity by up to 46 per cent; in actual in-field tasks, lifting windscreens weighing 13 and 17 kilograms, the reductions were smaller, up to 26 per cent, and one device received high discomfort scores in the shoulder region. Their recommendation is worth quoting in substance: analyse joint angles in the actual job before choosing a passive device, because the support depends on those angles, and pilot in the field. The most substantial longitudinal study to date is the 18-month field study at nine automotive manufacturing facilities led by Sunwook Kim and Maury Nussbaum of Virginia Tech, with Marty Smets of Ford, published in 2021. With 41 workers in the exoskeleton group and 83 controls in the main analysis, they found that across facilities, perceived work intensity and musculoskeletal discomfort did not differ significantly between groups over time, though some facilities showed suggestive improvements in neck and shoulder discomfort. A companion paper on usability and health outcomes reported that users perceived the exoskeleton as reducing demands on shoulders, neck and back, that fit and comfort strongly predicted intention to use, and that exoskeleton use might decrease the likelihood of medical visits. The cautious language is appropriate. Even this well-designed study could not establish a clear reduction in injury. Why laboratory gains shrink in the field The pattern of strong laboratory results and weaker, mixed field results is now well documented. It has several causes, each instructive for designers. Laboratory tasks are chosen to match the device. A back exoskeleton is tested on repeated stooped lifts, a shoulder exoskeleton on sustained overhead work. Real jobs mix many tasks: walking between stations, bending, reaching sideways, kneeling, sitting in a vehicle cab, climbing a ladder. A device that helps with one task may hinder others. Lukas Mitterlehner and colleagues, testing a commercial passive back exoskeleton in simulated logistics tasks in 2023, found mostly non-significant effects on heart rate, trunk posture and perceived exertion, highly variable effects on throughput between workstations, poor usability ratings and only moderate acceptance. Laboratory participants are typically young and fit, while workforces include older workers, people with existing musculoskeletal problems, and a wide range of body sizes. Fit problems that are minor for a laboratory volunteer may make a device unusable for a short or heavy worker. Laboratory sessions are short. Discomfort from pressure, heat and restriction accumulates over hours. A device that feels fine for thirty minutes may be intolerable by the end of an eight-hour shift. Muscle activity is not injury. Most laboratory studies measure surface EMG of the back or shoulder muscles and report the percentage reduction. That is a reasonable proxy for local muscle load, but it is not a measure of injury risk, which depends on peak and cumulative tissue loads in the spine, the shoulder joint and the muscles, and on recovery between exposures. A device that reduces erector spinae activity might increase load elsewhere, for example on the knees or on the abdominal muscles, or might change lifting technique in ways that increase spinal shear. Tjaša Kermavnar, Leonard O'Sullivan, de Looze and colleagues, updating the systematic review of back-support exoskeletons in Ergonomics in 2021, noted the predominance of short laboratory studies with young male participants and the scarcity of long-term field data. And workers are not passive recipients. They decide whether to wear the device, how to wear it and when to take it off. Shirley Elprama and colleagues in Brussels developed a framework of factors influencing acceptance, and later a typology of users and non-users, including people who try a device and discontinue it. A device that is uncomfortable, slow to don, socially awkward, or seen as a substitute for fixing a badly designed workstation will be rejected regardless of its biomechanical merits. Exoskeletons in the hierarchy of controls Occupational safety professionals use a hierarchy of controls to rank interventions: elimination of the hazard first, then substitution, engineering controls such as lift assists and redesigned workstations, administrative controls such as job rotation and training, and finally personal protective equipment. Exoskeletons, worn by individuals, sit low in that hierarchy, alongside personal protective equipment, even though they are technologically sophisticated. That placement matters. It means an exoskeleton should not be the first response to a hazardous lifting task. If the box can be raised to waist height, if a vacuum lifter or conveyor can take the load, if the task can be redesigned so that bending is unnecessary, those solutions are generally more effective and more reliable than asking the worker to wear a device. Exoskeletons make sense where those higher-order controls are impractical: tasks that vary too much for fixed equipment, work in spaces too confined for lift assists, jobs where the load is unpredictable. Baggage handling in an aircraft hold, picking in a warehouse with variable item sizes, construction work, nursing tasks involving patient handling where hoists are unavailable or too slow: these are plausible niches. Even there, the evidence suggests that devices work best when matched carefully to the task, introduced with training and a familiarisation period, and supported by an implementation process that involves workers in decisions. A practical illustration helps. Imagine a regional parcel depot considering back-support exoskeletons for staff who load roll cages. A careful implementation would begin not with a product catalogue but with a task analysis: video recordings or wearable motion sensors on a sample of workers through a full shift, measuring how often they bend, how deep, for how long, and how much of the shift is spent walking, reaching overhead or kneeling. Suppose the analysis shows that workers lift about three hundred parcels an hour, mostly from mid-thigh height into cages, with frequent walking between conveyor and cage. That profile suggests that the main exposure is repetitive moderate flexion rather than sustained deep stooping, that a device must not impede walking, and that donning must be quick because staff rotate between loading and other duties. A passive device with a fixed spring would help modestly on each lift but resist every step; a switchable textile device or a light active device with walking detection would fit better. The depot would then pilot two candidate devices with volunteers over several weeks, measure discomfort and actual hours worn as well as muscle activity on a subset, and involve workers in the decision. It might also discover during the analysis that raising the conveyor height by fifteen centimetres would cut the depth of flexion more than any exoskeleton, and do that first. Lessons for design The industrial experience feeds back into engineering in several ways. Mass matters even for devices worn on the trunk, because workers carry them all day and because weight on the shoulders adds load to the very structures the device aims to protect. Lightweight composite frames, discussed in Chapter 6, are relevant here, but so are textile designs that use the body as the frame. Switchability matters. A device that assists only when needed, either through a manual switch, a clutch or active control, avoids penalising the wearer during tasks it is not designed for. This argues for quasi-passive designs: springs that can be engaged and disengaged with minimal energy, combining the lightness of passive devices with some of the adaptability of active ones. Comfort at the interface is decisive. The chest pad of a back support or the arm cuffs of a shoulder support are where the device's forces enter the body, and the evidence from field studies repeatedly identifies discomfort at those points as a reason for rejection. The interface principles from Chapter 5 apply directly. Donning time and simplicity matter for devices shared among shifts. A device that takes several minutes to fit and adjust will be skipped when production pressure is high. And evaluation must extend beyond EMG reductions in laboratory tasks to field studies with real workers over weeks or months, measuring discomfort, acceptance, productivity, and ideally injury rates. Those studies are expensive and slow, which is why few exist. But without them, the industrial exoskeleton market rests on a plausible mechanism and promising short-term data rather than on demonstrated prevention of injury. The most honest summary of the evidence in 2026 is that well-matched devices reduce local muscle demand in the tasks they are designed for, that the benefit shrinks in mixed real-world work, and that whether they prevent injuries over years has not yet been shown. CHAPTER 8 Standing Up Again For a person who has lost the use of their legs through spinal cord injury, the image of a powered exoskeleton lifting them out of a wheelchair and walking them across a room is powerful in a way few technologies are. It has been used in advertisements, documentaries and fundraising campaigns, and a handful of users have walked marathons in exoskeletons over many hours. The image is real: people with complete paraplegia do stand and walk in these devices. But the image also obscures what the devices actually do, who can use them, what they cost, and what the evidence says about their benefits. This chapter is about the gap between the image and the engineering. The injury and the population The spinal cord carries signals between the brain and the body. When it is damaged, by trauma such as a vehicle crash, a fall, a sports injury or violence, or by disease, the functions served by the cord below the injury level are impaired or lost. In the United States, the National Spinal Cord Injury Statistical Center at the University of Alabama at Birmingham estimates roughly eighteen thousand new traumatic injuries each year and around three hundred thousand people living with spinal cord injury. Globally the numbers are many times larger. Injuries are classified by level and completeness. The level is the lowest segment of the cord with normal function: injuries in the cervical region produce tetraplegia, affecting arms as well as legs; injuries in the thoracic and lumbar regions produce paraplegia, affecting the trunk and legs to varying degrees. Completeness is graded on the American Spinal Injury Association Impairment Scale, from A, complete loss of motor and sensory function below the injury, through B, C and D with increasing preservation, to E, normal. A person with a T10 ASIA A injury has normal arms and upper trunk, partial trunk control and no voluntary leg function or sensation. The level and completeness of injury determine which exoskeleton, if any, a person can use. The current generation of wearable exoskeletons that require crutches for balance demand good arm and hand function, enough trunk control to manage weight shifts, and adequate range of motion in hips, knees and ankles. Most are therefore indicated for people with injuries in the thoracic or lower region. Higher injuries, with weaker trunk and arm function, generally exclude crutch-based devices, though self-balancing designs, discussed below, extend the range. Secondary conditions also matter. People with long-standing spinal cord injury lose bone mineral density in the legs rapidly in the first years after injury and continue to lose it more slowly afterward. The bones of the paralysed lower limbs become fragile, sometimes severely so. Joint contractures, in which tendons and joint capsules shorten from disuse, limit range of motion. Spasticity can cause sudden involuntary muscle contractions. Autonomic dysreflexia, a dangerous rise in blood pressure triggered by stimuli below the injury in people with higher-level injuries, can be provoked by pressure or pain the person cannot feel. Orthostatic hypotension, a drop in blood pressure on standing, is common after long periods of sitting. Each of these affects whether a person can safely use an exoskeleton and how training must proceed. The devices Four wearable exoskeletons have dominated the clinical and personal market for spinal cord injury in the past decade, joined more recently by a self-balancing design. As Table 4 sets out, they share a broad architecture, powered hips and knees on a rigid frame with passive or orthotic ankles, but they differ in how they detect intent, whether they require crutches and where they are used. Table 4. Principal lower-limb exoskeletons used in spinal cord injury rehabilitation. Device Origin Intent detection Balance aid Typical setting ReWalk (now Lifeward) Israel, Argo Medical Technologies Trunk tilt via inertial sensors, wrist controller Forearm crutches Personal and clinical Ekso (EksoGT, EksoNR) United States, Ekso Bionics Weight shift, buttons, therapist control Crutches or walker Clinical Indego United States, Vanderbilt and Parker Hannifin, now Ekso Trunk lean via inertial sensors Forearm crutches or walker Personal and clinical HAL lower limb Japan, Cyberdyne Surface EMG with mechanical sensing Walker or support Clinical Atalante France, Wandercraft Trunk motion, therapist control Self-balancing, hands free Clinical ReWalk was the first to reach the American market. Its origins lie in the work of Amit Goffer, an Israeli engineer who became tetraplegic after an accident in 1997 and founded Argo Medical Technologies to develop the device. The FDA's de novo clearance of ReWalk in 2014 created a new device classification, powered lower-extremity exoskeletons, as Class II devices subject to special controls. The company later renamed itself ReWalk Robotics and, in 2024, Lifeward, reflecting a broader product portfolio that by then included the AlterG anti-gravity treadmill and the ReStore exosuit for stroke. ReWalk's intent detection is mechanical: the user tilts the trunk forward, an inertial sensor detects the tilt, and the device takes a step. A wrist-worn controller selects modes such as sit, stand and walk. The user balances with forearm crutches throughout. Ekso Bionics, spun out of Homayoon Kazerooni's Berkeley laboratory, developed the Ekso GT, later EksoNR, primarily for clinical rehabilitation rather than personal use. Its software allows therapists to vary the level of assistance, from fully powered stepping for people with complete injuries to variable assistance that lets people with partial function contribute, which makes it useful across spinal cord injury, stroke and acquired brain injury. Ekso received FDA clearance for spinal cord injury and stroke in 2016. Indego, developed by Michael Goldfarb's group at Vanderbilt University and licensed to Parker Hannifin, was cleared for clinical and personal use in 2016. Its notable feature was modularity and low mass: the device separates into hip, thigh and shank pieces that can be assembled around a seated user, which simplifies donning from a wheelchair. Ekso Bionics acquired the Indego business from Parker Hannifin in early 2023. HAL, described in Chapter 1, is the outlier in using surface EMG for intent. In spinal cord injury, its target population is people with incomplete injuries who retain some voluntary activation that the device can amplify. Its proponents argue that this coupling of intention and movement promotes neural recovery; trials in Japan and Germany have reported functional improvements, though the strength of evidence for a recovery effect beyond intensive conventional training remains under discussion. HAL was cleared by the FDA in 2017 for use in clinical settings. Atalante, developed by the French company Wandercraft, takes a different approach: it is self-balancing. With a larger number of actuated joints, including the ankles in several planes, and a controller derived from bipedal robotics, it keeps the user upright without crutches, freeing the hands and removing the need for strong arms. The cost is size and mass: Atalante is considerably heavier and bulkier than crutch-based devices and is used in clinics rather than at home. Wandercraft received FDA clearance for its use in stroke rehabilitation in 2022 and has continued to expand its indications. Training, speed and what walking means Using a crutch-based exoskeleton is a learned skill. A typical training protocol, such as the one developed at the James J. Peters Veterans Affairs Medical Center in the Bronx and described by Pierre Asselin and colleagues in 2016, begins with screening: range of motion, bone density, skin integrity, cardiovascular response to standing. Users then learn to stand and sit, to balance with crutches, to shift weight, and finally to walk, first on level surfaces with a therapist close by, then progressively on more complex terrain. To be cleared for home use, a user typically must demonstrate a set of advanced skills with a trained companion, who must accompany them whenever they use the device. Training takes weeks to months. Allan Kozlowski, Thomas Bryce and Marcel Dijkers, in a 2015 study of learning to use the first-generation Ekso, enrolled 22 people with spinal cord injury; nine failed screening, and seven provided complete data. Of those seven, five learned to stand, walk and sit with contact-guard or close supervision, and their average walking speeds ranged from 0.11 to 0.21 metres per second. These numbers convey the reality of exoskeleton walking: deliberate, effortful and slow. How slow? Dennis Louie, Janice Eng and Tania Lam reviewed the published evidence on gait speed in powered exoskeletons for spinal cord injury in 2015 and found an average speed across studies of about 0.26 metres per second. For comparison, unimpaired adults typically walk at around 1.2 to 1.4 metres per second. Ajax Yang, Asselin and colleagues reported in the same year that seven of twelve ReWalk users in their hospital study reached speeds of at least 0.40 metres per second, a threshold sometimes associated with limited community ambulation, and that faster walkers needed less assistance. Speed improved with training, and the most proficient users walked considerably faster than the average. But the typical user walks at a fifth to a third of normal speed. Speed is not the only measure of walking. Exoskeleton walking also demands substantial upper-body effort to manage crutches, considerable concentration, and a companion for safety. It cannot easily handle doorways, crowds, uneven ground, kerbs or slopes beyond modest gradients. Stairs are possible with some devices, but slowly and with assistance. Getting into and out of the device from a wheelchair takes minutes. For practical mobility, the wheelchair remains far faster, safer and more efficient. People who use exoskeletons at home generally do so for exercise, health and the experience of standing and walking, not as a replacement for the wheelchair. That conclusion is supported by Rosanne van Dijsseldonk, Ilse van Nes, Alexander Geurts and colleagues' 2020 study in Scientific Reports, which tracked fourteen people with complete spinal cord injury using a ReWalk at home and in the community with no restrictions. Over about two and a half weeks, participants used the device on a median of nine days and took a median of around 3,200 steps in total, with a wide range. They used it mostly for exercise, about three-quarters of the time, and for social interaction, about a fifth; they were broadly satisfied with it, but reported its limitations as an assistive device for daily life. The health case If exoskeletons do not replace wheelchairs, the case for them rests on health benefits from standing and walking: improved cardiovascular fitness, bone density, body composition, bowel and bladder function, spasticity, pain and psychological well-being. These are plausible. Prolonged sitting and immobility after spinal cord injury contribute to cardiovascular disease, metabolic syndrome, osteoporosis, pressure injuries, bowel dysfunction and depression, and upright activity counters some of these effects. The evidence is suggestive but limited. Larry Miller, Angela Zimmermann and William Herbert's 2016 meta-analysis in Medical Devices: Evidence and Research pooled 14 studies with 111 patients. After training, 76 per cent could walk with no physical assistance from another person; the weighted mean six-minute walk distance was 98 metres; the physiological demand averaged about 3.3 metabolic equivalents, comparable to brisk walking for an unimpaired person in terms of perceived exertion. Improvements in spasticity were reported in 38 per cent of patients and in bowel regularity in 61 per cent. Antony Karelis and colleagues reported in 2016 that a six-week exoskeleton training programme in five people with chronic complete injuries increased leg lean mass and reduced fat mass, with a non-significant trend toward increased tibial bone density. Those studies share limitations: small samples, short durations, lack of control groups, heterogeneous populations and outcome measures, and selection of motivated participants who passed screening. Many benefits attributed to exoskeleton walking might equally come from other forms of standing or exercise, such as standing frames, functional electrical stimulation cycling or body-weight-supported treadmill training, which are cheaper. Randomised controlled trials comparing exoskeleton training with such alternatives over long periods are few. The strongest current statement is that exoskeleton walking is feasible, safe with appropriate screening and supervision, and provides moderate-intensity physical activity with plausible secondary benefits. For people with incomplete injuries, the question changes. Here the goal may be not just exercise but recovery of walking function, and exoskeletons are one of several tools for intensive gait training. The theory, supported by animal and human research on activity-dependent plasticity, is that repeated, intensive practice of stepping with appropriate sensory feedback can strengthen surviving neural pathways. Whether exoskeleton training produces more recovery than equally intensive conventional or treadmill training is still debated, and evidence suggests that the intensity and specificity of practice may matter more than the device used. Risks Exoskeleton use carries real risks, and engineering decisions shape them. Fractures are the most serious. Because bone density in the paralysed legs is often severely reduced, normal walking forces can break bones. Miller's meta-analysis reported a fracture incidence of 3.4 per cent during training in the studies it pooled. Frank van Herpen and colleagues described two fractures during exoskeleton use in a 2019 case report, illustrating the hazard. Screening protocols now usually include bone density measurement, typically by dual-energy X-ray absorptiometry, with thresholds below which exoskeleton use is not recommended. From an engineering standpoint, the risk is shaped by how the device loads the bones: torsional loads on the tibia from a foot that does not rotate with the leg, impact loads at heel strike, and bending loads at the knee from misalignment. Smooth trajectories, compliant foot interfaces and good alignment reduce the risk. Falls are an obvious concern for a device that stands a paralysed person upright. Miller's analysis found a fall incidence of 4.4 per cent, all in a first-generation tethered device and none causing injury. Modern training protocols require a companion or therapist and teach users how to respond when balance is lost. Self-balancing designs reduce fall risk in the clinic; crutch-based designs depend on the user's skill. Skin injury, discussed in Chapter 5, is the most frequent adverse event. Pressure and shear from cuffs, straps and foot plates on insensate skin can cause abrasions and, if ignored, deeper injuries. Inspection before and after use is standard. Device malfunction is also recorded. Caroline Charette and colleagues, in a 2023 systematic review of what helps and hinders the implementation of exoskeleton training programmes, identified frequent adverse events such as skin problems and falls, and frequent device malfunctions, as recurring barriers, alongside requirements for clinician training, time and resources. Access and cost Personal exoskeletons cost tens of thousands of dollars, and clinical models more. For years, the main obstacle to personal use in the United States was the absence of reimbursement. That changed in 2024, when the Centers for Medicare and Medicaid Services established a payment rate for personal exoskeletons under its brace benefit category, allowing eligible beneficiaries to obtain devices through Medicare. Private insurers and Medicare Advantage plans have followed in a piecemeal fashion; Lifeward, for example, has announced coverage decisions from several large Medicare Advantage insurers. Outside the United States, access depends on rehabilitation centres, research programmes, charities and personal means. Reimbursement decisions in turn depend on evidence, which brings the discussion back to the scarcity of long-term controlled trials. Payers want to know not only whether exoskeletons are safe but whether they produce health benefits that justify their cost compared with alternatives. Providing that evidence requires studies that are expensive, slow and difficult to blind. What would make a difference From an engineering perspective, the obstacles to wider use of exoskeletons in spinal cord injury are concrete. Speed and efficiency of walking are limited by the crutch-based balance strategy and by conservative trajectories. Self-balancing devices remove the crutches but at the cost of mass and size. A device that could balance itself while remaining light enough for home use would change the picture. That requires lighter actuators, better balance controllers and, inevitably, lighter frames, which brings the composite design of Chapter 6 to the centre. Donning, doffing and transfers consume time and effort every session. Devices designed around the transfer from wheelchair, with fewer straps, self-aligning joints and modular assembly, reduce the burden. Intent detection for people without lower-limb function remains crude: trunk tilt and buttons. Richer interfaces, from upper-body EMG to brain-computer interfaces, are being explored in research, but robustness and safety are paramount. For people with incomplete injuries, EMG-based approaches such as HAL's, and combinations of exoskeletons with spinal cord stimulation, are areas of active research. The combination is intriguing: epidural and transcutaneous spinal cord stimulation can enable voluntary activation of muscles below an injury in some people, and an exoskeleton could then assist and shape that activation. In 2024 the FDA authorised a transcutaneous spinal cord stimulation system from ONWARD Medical for improving upper-limb function after chronic spinal cord injury, a sign that such therapies are moving from laboratory to clinic. Most fundamentally, the field needs a clearer answer to what exoskeletons are for. If they are exercise machines that let people stand and walk for health, they compete with cheaper exercise options and must show superior benefit or adherence. If they are mobility devices, they must become much faster, lighter and more capable. If they are recovery tools for incomplete injuries, they must show more recovery than intensive conventional training. Each answer implies different engineering priorities, and conflating them has led to devices that try to be all three and are not quite enough of any. CHAPTER 9 Proving It Is Safe and Proving It Works A powered machine strapped to a human body, capable of producing tens of newton-metres of torque at the hip and knee, is a hazard by its nature. If it moves a joint beyond its natural range, it can dislocate it or break a bone. If it applies force at the wrong moment, it can cause a fall. If its battery overheats, it can burn the skin. If its controller misreads intent, it can fight the wearer. And if it does all of these things correctly but simply fails to deliver the benefit promised, it wastes money, time and the trust of users who had good reasons to hope. Safety and effectiveness are two distinct questions, and they are proved in different ways. This chapter treats both: the engineering practices and standards used to make exoskeletons safe, and the methods used to show that they do what they claim. It is placed last among the main chapters because the answers depend on everything that came before. The hazards of an exoskeleton arise from its coupling with the person, and the evidence of its effectiveness must come from people. Hazards specific to wearable robots Industrial robots are made safe largely by separation: fences, light curtains and interlocks keep people out of the robot's workspace, or, for collaborative robots, speed and force limits ensure contact is harmless. Neither strategy works for an exoskeleton. The person is inside the workspace by design, and the device must apply substantial forces to the body to be useful. Safety must be achieved through the design of the device and its control, not by keeping people away. The hazards fall into recognisable groups. Mechanical hazards include driving a joint beyond its anatomical range, pinching skin or fingers in moving parts, applying excessive force through cuffs and causing fractures in fragile bones. Control hazards include unintended motion from sensor faults or software errors, instability and oscillation, and incorrect intent detection leading to motion at the wrong time. Balance hazards include falls caused by the device or by its failure to respond to the user's loss of balance, and falls while donning or doffing. Electrical and thermal hazards include battery fires, burns from hot motors or electronics, and electric shock. And ergonomic hazards include skin injury from pressure and shear, musculoskeletal strain from poor fit and fatigue from carrying the device. Each hazard calls for layered protection. The principle, familiar from functional safety engineering in other industries, is that no single failure should lead to harm, and that the most reliable protections are the simplest. Mechanical joint limits are the most basic layer. Hard stops built into the joint, independent of software, physically prevent motion beyond a safe range. They should be set within the range of the individual user, which may be reduced by contractures in people with spinal cord injury, and they must be strong enough to stop the actuator at full torque without failing. Many devices also include adjustable stops so that the range can be set for each person. Torque and speed limits in the actuator and its electronics form the next layer. Current limits in the motor drive cap the torque the motor can produce regardless of what the controller commands. Speed limits prevent rapid motions. Mechanical slip clutches can limit torque transmitted to the joint even if the motor drive fails. Software monitoring and fault detection provide a third layer. Redundant sensors, such as two encoders on a joint, allow inconsistencies to be detected. Watchdog timers detect stalled software. Plausibility checks compare measured motion against expected motion and flag deviations. When a fault is detected, the device must enter a safe state, and defining the safe state is itself a design decision. For an industrial back support, cutting power to the motors is usually safe; the person simply bears the load themselves. For a rehabilitation exoskeleton supporting a paralysed person who is standing, cutting power would cause the knees to buckle and the person to collapse. The safe state might instead be to lock the joints in place, or to guide the person slowly into a sitting position. Many rehabilitation devices use brakes or non-back-drivable transmissions so that the joints hold position when unpowered. Human oversight is the final layer. In clinical use, therapists supervise; in personal use, trained companions must be present. Emergency stop buttons, accessible to the user and companion, allow motion to be halted. Risk management and standards Medical device manufacturers follow a formal risk management process defined by the international standard ISO 14971. They identify hazards, estimate the probability and severity of harm, implement controls, verify that the controls work and evaluate residual risk. Tools such as failure mode and effects analysis and fault tree analysis structure this work. The process is not a one-time exercise; it continues through the life of the product, incorporating data from use and complaints. A single line of a failure mode and effects analysis for a powered knee exoskeleton illustrates how the layers work together. Consider the failure "knee joint encoder reports an angle that is wrong by twenty degrees". The cause might be a loose magnet, a cable fault or electrical interference from the motor drive. The effect, if undetected, depends on the controller: a position-tracking controller would drive the knee to correct a non-existent error, moving the limb twenty degrees away from where it should be, possibly into hyperextension. The severity is high, because a fragile knee in a person with spinal cord injury could be injured. The analysis then lists the controls: a second, independent sensor on the joint, such as a motor-side encoder read through the gear ratio, whose disagreement with the joint encoder beyond a threshold triggers a fault; a hard stop preventing hyperextension regardless of command; a current limit capping the torque available to drive the joint; and a rate limit preventing sudden large motions. With these in place, the analysis estimates residual risk, and if it remains unacceptable, adds further controls. Every credible failure of every component receives this treatment, and the resulting document, often hundreds of lines long, becomes part of the regulatory submission and a living reference for the engineering team. Several standards address wearable robots specifically. ISO 13482, published in 2014, sets safety requirements for personal care robots, including physical assistant robots, a category that covers many non-medical exoskeletons. For medical devices, the IEC 60601 family of standards governs electrical safety and essential performance, and IEC 80601-2-78, published in 2019, sets particular requirements for medical robots used in rehabilitation, assessment, compensation or alleviation, a category that includes rehabilitation exoskeletons. In 2017 ASTM International established Committee F48 on exoskeletons and exosuits, which has since developed standards on terminology, test methods and labelling for industrial, medical, military and consumer devices. ISO has also published performance test methods for wearable robots, including methods for lower-back support robots. Table 5 summarises the principal standards. Table 5. Principal standards relevant to exoskeleton safety and performance. Standard Body Scope Typical applicability ISO 14971 ISO Risk management for medical devices All medical exoskeletons IEC 60601-1 IEC General electrical safety and essential performance of medical equipment Powered medical exoskeletons IEC 80601-2-78 IEC and ISO Particular requirements for rehabilitation and assistive medical robots Rehabilitation exoskeletons ISO 13482 ISO Safety of personal care robots, including physical assistant robots Non-medical wearable robots ASTM F48 series ASTM International Terminology, test methods, labelling for exoskeletons Industrial, medical and consumer devices In the United States, powered lower-extremity exoskeletons for medical use are regulated by the FDA as Class II devices under 21 CFR 890.3480, the classification created when ReWalk was cleared in 2014. The special controls for this classification require, among other things, clinical testing demonstrating safe use, performance testing of the device's durability, battery and electrical safety, software verification and validation, and labelling that includes training requirements. Most subsequent devices have been cleared through the 510(k) pathway by demonstrating substantial equivalence to a predicate. In the European Union, medical exoskeletons must meet the Medical Device Regulation, which since its full application in 2021 has raised requirements for clinical evidence and post-market surveillance. Industrial exoskeletons occupy a less defined space. In most jurisdictions they are not medical devices, and they are not personal protective equipment in the regulatory sense, although some have argued they should be treated as such. They are regulated as machinery, under instruments such as the EU Machinery Directive and its successor Machinery Regulation, and must meet general safety requirements. But there is no equivalent of FDA clearance requiring evidence of benefit. The burden of evaluating whether an industrial exoskeleton actually works falls on the purchasing employer. Testing on benches, dummies and people Verification that a device meets its specifications involves extensive bench testing. Joints are cycled millions of times under representative loads to test fatigue; frames are loaded statically to ultimate strength; batteries are tested for thermal runaway; electronics are tested for electromagnetic compatibility, which matters for EMG sensing as Chapter 2 described. Software is verified against requirements and, for medical devices, developed under processes defined by IEC 62304. Testing the interaction between device and body is harder. Mechanical leg phantoms, physical models of the human limb with realistic segment masses, joint stiffness and sometimes soft tissue layers, allow repeatable testing of alignment, interaction forces and controller behaviour without risk to people. Daniel Ferris's group at the University of Florida, for example, published a mechanical lower-limb phantom for testing knee exoskeletons in 2023. Phantoms cannot replicate the variability, adaptation and voluntary behaviour of a real person, but they catch many faults before human testing begins. Testing with people follows a staged progression: healthy volunteers first, then target users in controlled settings, then supervised use in realistic settings, then independent use. Each stage involves ethical review and informed consent, and for medical devices, regulatory approval of an investigational device. Measuring effectiveness Showing that an exoskeleton is safe is necessary but not sufficient. The device must also do what it claims, and here the methods differ by application. For augmentation devices aimed at reducing effort, metabolic cost measured by indirect calorimetry is the standard outcome. Its virtues are that it integrates the effects of the device across the whole body, including the cost of carrying its mass, and that it is objective. Its limitations are that it requires laboratory equipment, takes minutes to reach steady state, and captures only one aspect of benefit. A device that reduces metabolic cost but causes discomfort or changes gait in harmful ways is not a clear success. For industrial devices, the standard outcomes are surface EMG of target muscles, along with joint kinematics, perceived exertion, discomfort ratings and task performance. As Chapter 7 discussed, EMG reductions are a proxy for reduced muscle load, not a measure of reduced injury risk. Better outcomes would include estimates of spinal loading from musculoskeletal models, and ultimately injury incidence in long-term field studies. The latter are rare because they require large populations, long durations and careful control for confounding factors such as job changes. For rehabilitation devices, outcomes include walking speed, measured by tests such as the ten-metre walk; walking endurance, measured by the six-minute walk test; the level of assistance required; balance; and functional scales such as the Walking Index for Spinal Cord Injury. Secondary outcomes include bone density, body composition, spasticity, bowel and bladder function, pain and quality of life. The highest level of evidence comes from randomised controlled trials comparing exoskeleton training with an active control, ideally matched for dose of therapy. Such trials are difficult: blinding is impossible, recruitment is slow, populations are heterogeneous, and the active comparators themselves vary. A recurring problem across all applications is the choice of comparison. An augmentation device may reduce metabolic cost relative to walking in the same device with zero torque, but not relative to walking without it, because its mass imposes a cost that the assistance only partly offsets. Zhang and colleagues' 2017 result, about a quarter reduction, was relative to the device with zero torque; Slade and colleagues' 2022 result was relative to normal shoes, the more demanding and more relevant comparison. Readers of exoskeleton studies should always ask: compared with what? Usability and acceptance as outcomes The industrial and rehabilitation evidence both point to the same conclusion: devices that work in the laboratory may not be used in practice. Usability and acceptance are therefore outcomes, not afterthoughts. Standard instruments exist. The System Usability Scale is a short questionnaire widely used for technology; the Quebec User Evaluation of Satisfaction with Assistive Technology measures satisfaction with assistive devices; the NASA Task Load Index measures perceived workload. More importantly, objective measures of actual use, from device logs recording hours worn, steps taken or lifts assisted, provide data that self-reports cannot. Van Dijsseldonk's home-use study of ReWalk relied on step counts from the device's own software. Industrial deployments increasingly use connected devices that report usage. Long-term follow-up is the critical gap. Many studies end when the device is first deployed; few report whether it is still in use six months or a year later. Abandonment rates for assistive technology in general are known to be substantial, and there is no reason to think exoskeletons are immune. After the device ships Safety work does not end at clearance or sale. Medical device manufacturers must operate post-market surveillance: collecting complaints, investigating adverse events and reporting serious ones to regulators. In the United States, reports of device-related adverse events are collected in the FDA's MAUDE database, which researchers and clinicians can search, and the special controls for powered exoskeletons require ongoing attention to failures and misuse. In the European Union, the Medical Device Regulation tightened post-market obligations, including periodic safety update reports and post-market clinical follow-up. These systems have known weaknesses. Reporting depends on users and clinicians recognising and recording events; minor skin injuries or near-falls may never be reported; and adverse event databases record what happened without denominators, so rates cannot be calculated from them alone. Device logs, which record usage and faults automatically, help close the gap, and a manufacturer that analyses its fleet data systematically can detect patterns, such as a particular joint failing more often in hot climates or a particular controller mode associated with more emergency stops, long before they appear in published studies. Connected devices raise a newer category of hazard. An exoskeleton that communicates with a tablet for therapist control, or uploads data to a cloud service, or receives software updates over a network, presents a cybersecurity surface. An unauthorised command to a device worn by a paralysed person is a safety problem, not just a privacy problem. Regulators now expect cybersecurity to be addressed in medical device submissions, including threat modelling, secure update mechanisms and plans for managing vulnerabilities after release. For industrial devices that report usage to employers, data governance raises separate questions: what the employer may learn about a worker's movements, fatigue or health from the device's logs, and who controls that information. Workers who suspect that an exoskeleton is also a monitoring device are less likely to accept it. Software updates themselves deserve care. A change to a controller's parameters, or to its intent-detection model, changes how the device behaves on the body. For a medical device, significant changes may require new regulatory review. For a learned controller of the kind described in Chapter 3, retraining on new data changes its behaviour in ways that are hard to characterise fully. The principle that guides responsible practice is that every behavioural change should be verified against the same safety requirements as the original, with the same layers of independent protection unchanged beneath it, so that a flawed update degrades performance rather than causing harm. Designing for evidence The final lesson of this chapter is that evidence should be designed in from the beginning. A device whose controller logs its state, the user's interaction and its own faults generates data for safety monitoring, effectiveness studies and design improvement. A device designed with its intended outcome in mind, whether metabolic cost, muscle load, walking speed or recovery, can be tuned and validated against that outcome. And a development programme that plans its clinical or field trials alongside its hardware, rather than after it, will reach a convincing answer sooner. The human-in-the-loop optimisation methods of Chapter 4 point in this direction. When a device can measure or estimate its own effect on the person and adjust accordingly, the distinction between design, control and evaluation begins to blur. The device becomes, in a sense, its own experiment. That is a powerful idea, and it raises its own questions about safety, since a controller that changes its behaviour must remain within safe bounds while it searches, and about regulation, since a device whose behaviour adapts after clearance is harder to certify than one whose behaviour is fixed. Regulators have begun to address adaptive software in other medical devices, and exoskeletons will need similar frameworks. Conclusion The cover of this book promises three things: myoelectric control, the translation of intent into torque, and lightweight carbon-fibre frames. Having followed each through to the people who wear these machines, it is possible to say something about them that could not be said at the start. None of the three is the bottleneck it appears to be. The bottleneck is the coupling between machine and person, and the field's progress over the past decade has come almost entirely from taking that coupling more seriously, not from better motors, better materials or cleverer signal processing on their own. Consider what the chapters show when read together. The largest improvement in augmentation performance in recent years did not come from a new actuator; it came from human-in-the-loop optimisation, which tuned a laboratory emulator to the individual and achieved reductions in metabolic cost that generic, one-size-fits-all assistance profiles did not approach. The largest obstacle to industrial adoption is not insufficient assistive torque; it is the chest pad, the harness, the donning time and the mismatch between laboratory tasks and real jobs. The main limit on rehabilitation exoskeletons is not their motors, which are adequate, but the crutch-based balance strategy, the transfer from the wheelchair, the fragility of the user's bones and the absence of evidence that walking in them yields more benefit than cheaper alternatives. In each case, the problem lies at the place where the machine meets the human: in information, in energy or in structure. What follows for myoelectric control The argument of this book implies a narrower but more secure role for myoelectric control than enthusiasts once hoped. At the two ends of the continuum of user contribution, it has been largely displaced. For people with complete paralysis, there is no voluntary lower-limb signal to read, and every commercially successful device uses trunk motion and explicit commands. For healthy users in industry and for augmentation of walking, mechanical sensing combined with learned estimates of biological joint moment now does much of what EMG was meant to do, with far less fragility. The 2024 demonstration that a hip exoskeleton could assist across many tasks using estimated joint moments from mechanical sensors alone marks a turning point. Where EMG retains a clear advantage is in the middle of the continuum, and that is also where the clinical need is greatest. For people with incomplete spinal cord injury, stroke or neuromuscular disease, the residual muscle signal is the most direct evidence of what the nervous system is trying to do, and a device that amplifies it may support recovery as well as movement. It is also the population in which EMG is hardest to interpret: weak, distorted by spasticity and changing over weeks. The engineering agenda that follows is specific. It calls for high-density recording and motor unit decomposition robust enough for daily clinical use, for musculoskeletal models that can be calibrated in minutes rather than hours, and for controllers that treat EMG as one input among several, trusted for anticipation and magnitude but checked against mechanics for direction and timing. What follows for frames and actuators The material and actuator chapters lead to a similar reframing. Carbon fibre matters because mass placement matters, and mass placement matters because the wearer pays for every distal gram with every step. A designer who specifies carbon composites for the hip housing while leaving a heavy motor on the shank has missed the point. The right sequence is to decide first where mass can go, move actuators proximally where possible, and then use the lightest stiff structure for the segments that must remain distal. In many devices that means a hybrid of machined metal joints and composite segments, carefully isolated from galvanic contact, with adjustment placed in the metal. Actuator choice follows from the user's place on the continuum, not from a ranking of technologies. Back-drivability is essential at the high-contribution end and nearly irrelevant at the low-contribution end. A rehabilitation device and an augmentation device can share almost nothing below the controller and still both be well designed. What remains unsettled Several questions this book has raised cannot yet be answered, and honesty requires naming them. It is not known whether industrial exoskeletons prevent injuries. They reduce local muscle demand in matched tasks; whether that translates into fewer back or shoulder disorders over years, in real workforces, has not been demonstrated. The 18-month automotive study is the best evidence so far, and it found suggestive rather than conclusive effects. The studies that would settle the question are large, long and expensive, and few employers or manufacturers have an incentive to fund them. It is not known whether walking in an exoskeleton yields health benefits for people with complete spinal cord injury beyond what standing frames, electrical stimulation cycling or other exercise provide. Feasibility and safety are established; superiority is not. With Medicare payment now available in the United States, the question has acquired financial weight, and the absence of long-term controlled trials becomes harder to excuse. It is not known how to certify a controller that keeps learning. Human-in-the-loop optimisation and data-driven intent estimation are the most promising developments in the field, and both produce devices whose behaviour changes after they leave the factory. Regulators have begun to address adaptive software elsewhere in medicine, but exoskeletons, which act directly on the body with substantial force, present the problem in an acute form. The answer will probably involve fixed safety layers that no adaptation can override, combined with bounded adaptation above them, but the details are unsettled. And it is not known whether a self-balancing exoskeleton can be made light and compact enough for daily home use. If it can, it would remove the dependence on crutches, open the technology to people with higher injuries and transform the practical value of exoskeletons as mobility devices. Doing so requires advances in actuator torque density, balance control and lightweight structure at once, which is why it has not yet happened. What readers should do differently For engineers, the practical consequence is to design from the body outward. Begin with the interface: what loads this person's tissue can bear, where, for how long; what range of bodies must fit; how the device will be put on and taken off. Let that set the actuator requirements, and let the actuator and interface together set the frame. Build logging into every prototype, define the comparison that matters before the first test, and treat the person's adaptation as part of the system rather than as noise. For clinicians and rehabilitation managers, the consequence is to decide what an exoskeleton is for before buying one. If it is for exercise and health, compare it honestly with cheaper options and measure adherence. If it is for recovery in incomplete injury or stroke, ensure that the training dose is high and that the device does not do so much that the patient stops trying. If it is for personal mobility, be candid with users about speed, effort and the companion requirement. For employers, the consequence is to place the exoskeleton where it belongs in the hierarchy of controls: after redesigning the task, not instead of it. Analyse the job, pilot with volunteers in the real workplace, measure discomfort and actual use as well as muscle activity, and expect the benefit to be smaller than the brochure suggests. For anyone reading a claim about an exoskeleton, whether in a paper, a press release or an investor deck, the consequence is to ask three questions. Compared with what: no device, the device switched off, or an alternative intervention? Measured on whom: young laboratory volunteers or the people who will actually wear it? And for how long: a thirty-minute session or a year of daily life? Those three questions, applied consistently, would have prevented most of the field's disappointments, and they will separate the devices that help from the devices that merely impress. Hardiman failed because it treated the human as a source of commands and the machine as a source of force. Sixty years on, the machines that work are the ones that treat the human as the other half of the mechanism: to be listened to, fitted, adapted to and measured. That is not a limitation on exoskeleton engineering. It is what exoskeleton engineering is. Notes Chapter 1 1. Collins, S. H., Wiggin, M. B., and Sawicki, G. S. "Reducing the energy cost of human walking using an unpowered exoskeleton." Nature 522 (2015): 212–215. 2. Zhang, J., Fiers, P., Witte, K. A., Jackson, R. W., Poggensee, K. L., Atkeson, C. G., and Collins, S. H. "Human-in-the-loop optimization of exoskeleton assistance during walking." Science 356 (2017): 1280–1284. 3. Mooney, L. M., Rouse, E. J., and Herr, H. M. "Autonomous exoskeleton reduces metabolic cost of human walking during load carriage." Journal of NeuroEngineering and Rehabilitation 11 (2014): 80. 4. Kawamoto, H., and Sankai, Y. "Power assist method based on phase sequence and muscle force condition for HAL." Advanced Robotics 19 (2005): 717–734. 5. Browning, R. C., Modica, J. R., Kram, R., and Goswami, A. "The effects of adding mass to the legs on the energetics and biomechanics of walking." Medicine & Science in Sports & Exercise 39 (2007): 515–525. 6. Young, A. J., and Ferris, D. P. "State of the art and future directions for lower limb robotic exoskeletons." IEEE Transactions on Neural Systems and Rehabilitation Engineering 25 (2017): 171–182. Chapter 2 1. Merletti, R., and Farina, D., eds. Surface Electromyography: Physiology, Engineering, and Applications. Hoboken, NJ: Wiley-IEEE Press, 2016. 2. Hermens, H. J., Freriks, B., Disselhorst-Klug, C., and Rau, G. "Development of recommendations for SEMG sensors and sensor placement procedures." Journal of Electromyography and Kinesiology 10 (2000): 361–374. 3. Englehart, K., and Hudgins, B. "A robust, real-time control scheme for multifunction myoelectric control." IEEE Transactions on Biomedical Engineering 50 (2003): 848–854. Chapter 3 1. Hudgins, B., Parker, P., and Scott, R. N. "A new strategy for multifunction myoelectric control." IEEE Transactions on Biomedical Engineering 40 (1993): 82–94. 2. Ferris, D. P., Gordon, K. E., Sawicki, G. S., and Peethambaran, A. "An improved powered ankle-foot orthosis using proportional myoelectric control." Gait & Posture 23 (2006): 425–428. 3. Sawicki, G. S., and Ferris, D. P. "Mechanics and energetics of incline walking with robotic ankle exoskeletons." Journal of Experimental Biology 212 (2009): 32–41. 4. Scheme, E. J., Hudgins, B. S., and Englehart, K. B. "Confidence-based rejection for improved pattern recognition myoelectric control." IEEE Transactions on Biomedical Engineering 60 (2013): 1563–1570. 5. Lloyd, D. G., and Besier, T. F. "An EMG-driven musculoskeletal model to estimate muscle forces and knee joint moments in vivo." Journal of Biomechanics 36 (2003): 765–776. 6. Durandau, G., Farina, D., and Sartori, M. "Robust real-time musculoskeletal modeling driven by electromyograms." IEEE Transactions on Biomedical Engineering 65 (2018): 556–564. 7. Molinaro, D. D., Scherpereel, K. L., Schonhaut, E. B., Evangelopoulos, G., Shepherd, M. K., and Young, A. J. "Task-agnostic exoskeleton control via biological joint moment estimation." Nature 635 (2024): 337–344. 8. Shepherd, M. K., Schonhaut, E. B., Scherpereel, K. L., Tourk, F. M., and Young, A. J. "A roadmap for end-to-end task-agnostic exoskeleton control." Nature Machine Intelligence 8 (2026): 1347–1357. 9. Scherpereel, K. L., Molinaro, D. D., Shepherd, M. K., Inan, O. T., and Young, A. J. "Improving biological joint moment estimation during real-world tasks with EMG and instrumented insoles." IEEE Transactions on Biomedical Engineering 71 (2024): 2718–2727. 10. Farrell, T. R., and Weir, R. F. "The optimal controller delay for myoelectric prostheses." IEEE Transactions on Neural Systems and Rehabilitation Engineering 15 (2007): 111–118. Chapter 4 1. Winter, D. A. Biomechanics and Motor Control of Human Movement. 4th ed. Hoboken, NJ: Wiley, 2009. 2. Pratt, G. A., and Williamson, M. M. "Series elastic actuators." Proceedings of the 1995 IEEE/RSJ International Conference on Intelligent Robots and Systems, vol. 1, 399–406. 3. Yu, S., Huang, T.-H., Yang, X., Jiao, C., Yang, J., Chen, Y., Yi, J., and Su, H. "Quasi-direct drive actuation for a lightweight hip exoskeleton with high backdrivability and high bandwidth." IEEE/ASME Transactions on Mechatronics 25 (2020): 1794–1802. 4. Kim, J., Lee, G., Heimgartner, R., et al. "Reducing the metabolic rate of walking and running with a versatile, portable exosuit." Science 365 (2019): 668–672. 5. Hogan, N. "Impedance control: an approach to manipulation," Parts I–III. Journal of Dynamic Systems, Measurement, and Control 107 (1985): 1–24. 6. Slade, P., Kochenderfer, M. J., Delp, S. L., and Collins, S. H. "Personalizing exoskeleton assistance while walking in the real world." Nature 610 (2022): 277–282. 7. Awad, L. N., Bae, J., O'Donnell, K., et al. "A soft robotic exosuit improves walking in patients after stroke." Science Translational Medicine 9 (2017): eaai9084. 8. Mooney, L. M., and Herr, H. M. "Biomechanical walking mechanisms underlying the metabolic reduction caused by an autonomous exoskeleton." Journal of NeuroEngineering and Rehabilitation 13 (2016). Chapter 5 1. Yandell, M. B., Quinlivan, B. T., Popov, D., Walsh, C., and Zelik, K. E. "Physical interface dynamics alter how robotic exosuits augment human movement: implications for optimizing wearable assistive devices." Journal of NeuroEngineering and Rehabilitation 14 (2017): 40. 2. Landis, E. M. "Micro-injection studies of capillary blood pressure in human skin." Heart 15 (1930): 209–228. 3. Schiele, A., and van der Helm, F. C. T. "Kinematic design to improve ergonomics in human machine interaction." IEEE Transactions on Neural Systems and Rehabilitation Engineering 14 (2006): 456–469. 4. Sanchez-Balandran, J., Martinez Fernandez, A., Tovar, L., et al. "Task complexity in exoskeleton setup and takedown: procedural steps and usability problems as predictors of deployment performance." PLOS ONE (2026). Chapter 6 1. Representative material properties are drawn from standard handbook data for the metal grades listed and from manufacturer data for standard-modulus carbon fibre of the T700 class. Detailed treatment of laminate design is given in Daniel, I. M., and Ishai, O. Engineering Mechanics of Composite Materials. 2nd ed. New York: Oxford University Press, 2006. Chapter 7 1. GBD 2021 Low Back Pain Collaborators. "Global, regional, and national burden of low back pain, 1990–2020, its attributable risk factors, and projections to 2050." The Lancet Rheumatology 5 (2023). 2. Waters, T. R., Putz-Anderson, V., Garg, A., and Fine, L. J. "Revised NIOSH equation for the design and evaluation of manual lifting tasks." Ergonomics 36 (1993): 749–776. 3. Bosch, T., van Eck, J., Knitel, K., and de Looze, M. "The effects of a passive exoskeleton on muscle activity, discomfort and endurance time in forward bending work." Applied Ergonomics 54 (2016): 212–217. 4. Lamers, E. P., and Zelik, K. E. "Design, modeling, and demonstration of a new dual-mode back-assist exosuit with extension mechanism." Wearable Technologies 2 (2021): e1. 5. Poliero, T., Fanti, V., Sposito, M., et al. "Active and passive back-support exoskeletons: a comparison in static and dynamic tasks." IEEE Robotics and Automation Letters (2022). 6. De Bock, S., Ghillebert, J., Govaerts, R., et al. "Passive shoulder exoskeletons: more effective in the lab than in the field?" IEEE Transactions on Neural Systems and Rehabilitation Engineering (2020). 7. Kim, S., Nussbaum, M. A., Smets, M., et al. "Effects of an arm-support exoskeleton on perceived work intensity and musculoskeletal discomfort: an 18-month field study in automotive assembly." American Journal of Industrial Medicine 64 (2021). 8. Kim, S., Nussbaum, M. A., and Smets, M. "Usability, user acceptance, and health outcomes of arm-support exoskeleton use in automotive assembly." Journal of Occupational and Environmental Medicine (2022). 9. Mitterlehner, L., Li, Y. X., and Wolf, M. "Objective and subjective evaluation of a passive low-back exoskeleton during simulated logistics tasks." Wearable Technologies 4 (2023). 10. Kermavnar, T., de Vries, A. W., de Looze, M. P., and O'Sullivan, L. W. "Effects of industrial back-support exoskeletons on body loading and user experience: an updated systematic review." Ergonomics 64 (2021): 685–711. 11. de Looze, M. P., Bosch, T., Krause, F., Stadler, K. S., and O'Sullivan, L. W. "Exoskeletons for industrial application and their potential effects on physical work load." Ergonomics 59 (2016): 671–681. 12. Elprama, S. A., Vanderborght, B., and Jacobs, A. "An industrial exoskeleton user acceptance framework based on a literature review of empirical studies." Applied Ergonomics (2022): 103615. Chapter 8 1. Esquenazi, A., Talaty, M., Packel, A., and Saulino, M. "The ReWalk powered exoskeleton to restore ambulatory function to individuals with thoracic-level motor-complete spinal cord injury." American Journal of Physical Medicine & Rehabilitation 91 (2012): 911–921. 2. Asselin, P. K., Avedissian, M., Knezevic, S., et al. "Training persons with spinal cord injury to ambulate using a powered exoskeleton." Journal of Visualized Experiments (2016): e54071. 3. Kozlowski, A. J., Bryce, T. N., and Dijkers, M. P. "Time and effort required by persons with spinal cord injury to learn to use a powered exoskeleton for assisted walking." Topics in Spinal Cord Injury Rehabilitation 21 (2015): 110. 4. Louie, D. R., Eng, J. J., and Lam, T. "Gait speed using powered robotic exoskeletons after spinal cord injury: a systematic review and correlational study." Journal of NeuroEngineering and Rehabilitation 12 (2015): 82. 5. Yang, A. H., Asselin, P. K., Knezevic, S., et al. "Assessment of in-hospital walking velocity and level of assistance in a powered exoskeleton in persons with spinal cord injury." Topics in Spinal Cord Injury Rehabilitation 21 (2015): 100. 6. van Dijsseldonk, R. B., van Nes, I. J. W., Geurts, A. C. H., et al. "Exoskeleton home and community use in people with complete spinal cord injury." Scientific Reports 10 (2020). 7. Miller, L. E., Zimmermann, A. K., and Herbert, W. G. "Clinical effectiveness and safety of powered exoskeleton-assisted walking in patients with spinal cord injury: systematic review with meta-analysis." Medical Devices: Evidence and Research 9 (2016). 8. Karelis, A. D., Carvalho, L. P., Castillo, M., et al. "Effect on body composition and bone mineral density of walking with a robotic exoskeleton in adults with chronic spinal cord injury." Journal of Rehabilitation Medicine (2016). 9. van Herpen, F. H. M., van Dijsseldonk, R. B., Rijken, H., et al. "Case report: description of two fractures during the use of a powered exoskeleton." Spinal Cord Series and Cases (2019). 10. Charette, C., Déry, J., Blanchette, A. K., et al. "A systematic review of the determinants of implementation of a locomotor training program using a powered exoskeleton for individuals with a spinal cord injury." Clinical Rehabilitation (2023). 11. National Spinal Cord Injury Statistical Center. Traumatic Spinal Cord Injury Facts and Figures at a Glance. Birmingham, AL: University of Alabama at Birmingham, published annually. Chapter 9 1. US Food and Drug Administration. 21 CFR 890.3480, Powered lower extremity exoskeleton. 2. International Organization for Standardization. ISO 13482:2014, Robots and robotic devices — Safety requirements for personal care robots. 3. International Electrotechnical Commission. IEC 80601-2-78:2019, Medical electrical equipment — Part 2-78: Particular requirements for basic safety and essential performance of medical robots for rehabilitation, assessment, compensation or alleviation. 4. International Organization for Standardization. ISO 14971:2019, Medical devices — Application of risk management to medical devices. 5. Barrutia, W. S., Bratt, J., and Ferris, D. P. "A human lower limb mechanical phantom for the testing of knee exoskeletons." IEEE Transactions on Neural Systems and Rehabilitation Engineering 31 (2023): 2497–2506. Glossary Admittance control. A control strategy in which the device measures the force applied by the user and responds with motion, as if it were a virtual mass and damper being pushed. ASIA Impairment Scale. The American Spinal Injury Association's grading of spinal cord injury completeness, from A (complete loss of motor and sensory function below the injury) to E (normal function). Back-drivability. The ease with which a person can move an actuator's output by hand when the motor is idle; determined mainly by gear ratio, reflected inertia and friction. Electromechanical delay. The interval between the onset of electrical activity in a muscle and the onset of measurable force, typically tens of milliseconds. Exosuit. A soft, textile-based wearable robot that applies forces through cables or straps and relies on the wearer's skeleton to bear compressive loads. Human-in-the-loop optimisation. A method of tuning assistance parameters while the person wears the device, using a measured or estimated outcome such as metabolic cost to guide the search. Impedance control. A control strategy in which the device behaves like a virtual spring and damper, regulating the relationship between motion and force rather than either alone. Motor unit. A single motor neuron together with all the muscle fibres it innervates; the basic unit of muscle activation. Pattern recognition (myoelectric). Classification of short windows of multichannel EMG into discrete movement or mode classes using extracted features and a trained classifier. Quasi-direct drive. An actuator using a high-torque motor with a low gear ratio, typically under 10:1, giving high back-drivability and allowing torque to be estimated from motor current. Series elastic actuator. An actuator with a deliberately compliant spring between the motor-gearbox and the load, whose deflection is measured to control output force. Transparency. The degree to which an exoskeleton with zero commanded assistance imposes no forces on the wearer other than those due to its unavoidable mass. Further Reading Pons, J. L., ed. Wearable Robots: Biomechatronic Exoskeletons. Chichester: Wiley, 2008.** An early and still useful engineering overview of exoskeleton design, covering biomechanics, actuation, sensing and the human-robot interface, written by the research community that built the first generation of European devices. Merletti, R., and Farina, D., eds. Surface Electromyography: Physiology, Engineering, and Applications. Hoboken, NJ: Wiley-IEEE Press, 2016.** The standard reference on how surface EMG is generated, recorded and processed, including high-density recording and motor unit decomposition. Essential background for anyone designing myoelectric control. Winter, D. A. Biomechanics and Motor Control of Human Movement. 4th ed. Hoboken, NJ: Wiley, 2009.** The classic text on human movement biomechanics, with the joint moment and power data on which much exoskeleton design rests. Young, A. J., and Ferris, D. P. "State of the art and future directions for lower limb robotic exoskeletons." IEEE Transactions on Neural Systems and Rehabilitation Engineering 25 (2017).** A concise, critical review by two leading researchers, distinguishing what had been shown from what had been claimed. Zhang, J., et al. "Human-in-the-loop optimization of exoskeleton assistance during walking." Science 356 (2017); and Slade, P., et al. "Personalizing exoskeleton assistance while walking in the real world." Nature 610 (2022).** Read together, these two papers trace the idea of personalised assistance from a tethered laboratory emulator to a portable device used on city streets. Molinaro, D. D., et al. "Task-agnostic exoskeleton control via biological joint moment estimation." Nature 635 (2024).** The clearest current statement of the data-driven approach to intent estimation, with a single controller assisting across many tasks. Hogan, N. "Impedance control: an approach to manipulation," Parts I–III. Journal of Dynamic Systems, Measurement, and Control 107 (1985).** The foundational papers on controlling the dynamic relationship between a robot and its environment, as relevant to exoskeletons as to manipulators. Daniel, I. M., and Ishai, O. Engineering Mechanics of Composite Materials. 2nd ed. New York: Oxford University Press, 2006.** A rigorous introduction to laminate theory, failure and design for readers who need to go beyond the principles set out in Chapter 6. Kermavnar, T., et al. "Effects of industrial back-support exoskeletons on body loading and user experience: an updated systematic review." Ergonomics 64 (2021).** The most useful single review of the industrial back-support evidence, with clear attention to its limitations. De Bock, S., et al. "Passive shoulder exoskeletons: more effective in the lab than in the field?" IEEE Transactions on Neural Systems and Rehabilitation Engineering (2020).** A short, careful study whose title states the central problem of industrial exoskeleton evaluation. Miller, L. E., Zimmermann, A. K., and Herbert, W. G. "Clinical effectiveness and safety of powered exoskeleton-assisted walking in patients with spinal cord injury: systematic review with meta-analysis." Medical Devices: Evidence and Research 9 (2016).** A compact summary of what the early clinical studies of ReWalk, Ekso and Indego showed, including adverse event rates. Wearable Technologies (Cambridge University Press). An open-access journal founded in 2020 that publishes much of the current work on exoskeletons, exosuits and their evaluation, including field studies and design papers. Hashtags: #ExoskeletonEngineering #ExoskeletonTechnology #WearableRobotics #WearableExoskeletons #RoboticExoskeletons #RehabilitationRobotics #HumanAugmentation #HumanMachineInteraction #HumanRobotInteraction #AssistiveTechnology #AssistiveRobotics #BiomechanicalEngineering #Biomechanics #BiomedicalEngineering #MedicalRobotics #RoboticRehabilitation #PhysicalRehabilitation #MobilityAssistance #GaitRehabilitation #GaitTraining #SpinalCordInjuryRehabilitation #StrokeRehabilitation #Neurorehabilitation #Neuroplasticity #LowerLimbExoskeleton #IndustrialExoskeletons #IndustrialErgonomics #OccupationalHealth #WorkplaceSafety #LiftingAssistance #BackSupportExoskeletons #SoftExosuits #PoweredExoskeletons #PassiveExoskeletons #MyoelectricControl #Electromyography #SurfaceEMG #MuscleActivityMonitoring #HumanIntentDetection #IntentRecognition #MusculoskeletalModeling #SensorFusion #GaitAnalysis #GaitPhaseDetection #AssistAsNeededControl #AdaptiveControl #ImpedanceControl #AdmittanceControl #TorqueControl #HumanInTheLoopOptimization #PersonalizedAssistance #ExoskeletonActuators #SeriesElasticActuators #QuasiDirectDrive #BowdenCableActuation #Backdrivability #JointTorqueAssistance #HumanRobotCoupling #HumanExoskeletonInterface #WearableSensors #CarbonFiberComposites #LightweightRobotics #CompositeFrameDesign #ErgonomicDesign #MetabolicCostReduction #MobilityRestoration #RehabilitationEngineering #ExoskeletonSafety #MedicalDeviceValidation #WearableTechnology

Download the Book (PDF): Introduction A child who has seen horses but never a zebra can be told, once, that a zebra is a horse-shaped animal with black and white stripes, and will then pick out a zebra at the zoo without hesitation. Nothing in her visual experience was labeled "zebra." What she had instead was a description, a set of concepts she already understood, and the ability to combine them. The recognition happened because the words carried enough structure to locate the new animal among the old ones. That small act is the whole problem of zero-shot learning in miniature. A model is trained to recognize some set of categories. At test time it is asked to recognize categories it never saw a single example of. It cannot do this from images alone, because nothing in the images tells it what the new categories are called or where their boundaries lie. It needs a second source of information about the categories themselves: a list of attributes, a sentence of description, a position in a word-embedding space, a node in a knowledge graph, or a text prompt fed to a model that has read a large fraction of the public internet. Zero-shot learning is the study of how to connect that second source to the first, so that knowledge about known categories transfers to unknown ones. This booklet argues one thing throughout. Zero-shot generalization is borrowed, never conjured. Every zero-shot system works by building a bridge between the space where inputs live (pixels, sounds, sentences) and a space where categories are described (attributes, words, text). Whatever the system knows about an unseen category, it knows because that category's description sits in a meaningful place on the far side of the bridge, and because the bridge was built well enough to carry the input to roughly the right place. When zero-shot learning succeeds, it is because the semantic space encodes the structure the task needs and the mapping preserves it. When it fails, and it fails in characteristic ways, the failure can almost always be traced to one of those two conditions breaking down. This framing matters because the field has changed dramatically, and it is easy to mistake the change for a different kind of thing altogether. For roughly a decade, from 2008 to 2019, zero-shot learning was a fairly specialized research area. Its workhorse benchmarks were small: fifty animal species with eighty-five hand-annotated attributes each, two hundred bird species described by three hundred and twelve visual properties, a few hundred scene types. Researchers argued over how to map image features into attribute space, discovered that the mappings developed pathologies in high dimensions, found that many reported results were inflated by flawed evaluation protocols, and turned to generative models that could synthesize training features for classes no one had photographed. Then, in early 2021, OpenAI released CLIP, a model trained to match four hundred million images to their accompanying text. Without any training on ImageNet, CLIP could classify ImageNet images by comparing each image to sentences such as "a photo of a goldfinch," and its best version matched the accuracy of a ResNet-50 trained on ImageNet's 1.28 million labeled examples. Large language models showed a parallel ability in text: given a task described in words, they could perform it without task-specific training. "Zero-shot" migrated from a niche benchmark setting to a headline capability of general-purpose foundation models, and the vocabulary of attributes and compatibility functions seemed to fade. The bridge did not go away. CLIP is a visual-semantic embedding model of exactly the kind researchers had been building since 2013, trained with a contrastive objective on vastly more and vastly messier data. Its text encoder is the side-information source; its image encoder is the input mapping; its shared embedding space is the bridge. What changed is that the semantic side became natural language at internet scale rather than a curated attribute table, and the "seen" classes became, in effect, every concept that appears often enough in captions. That change has enormous practical consequences. It also raises an uncomfortable question the older literature was forced to confront head on: how unseen is an "unseen" class, really, when the training corpus contains millions of images of it with its name attached? Recent work suggests that the zero-shot performance of these models on a concept rises roughly with the logarithm of how often the concept appears in the pretraining data. The generalization is real, but it is borrowed from the data, just as the older methods borrowed it from attribute annotations. Seeing the continuity is useful in three ways. It makes the history legible: each generation of methods is an attempt to fix a specific weakness in the bridge left by the previous one. It makes the failures predictable: hubness, domain shift, bias toward seen classes, sensitivity to the wording of descriptions, and collapse on rare or compositional concepts all have identifiable causes. And it makes practice more disciplined: if you are building a system that must recognize things nobody has labeled, the questions you need to ask are about your semantic space and your mapping, not about whether the method carries the label "zero-shot." What the chapters do The first chapter defines the problem carefully. It separates the conventional setting, in which test images come only from unseen classes, from the generalized setting, in which they may come from either, and it sets out the forms side information can take. It traces the problem's origins to three papers published in 2008 and 2009 that framed it in recognizably modern terms. The second chapter examines attributes, the first and most interpretable bridge. Attributes such as "striped," "has hooves," or "lives in water" were attractive because humans can name and annotate them, and because they decompose categories into shareable parts. The chapter explains how direct and indirect attribute prediction work, why attributes are both powerful and brittle, and what the cost of annotating them taught the field. The third chapter covers the move from attributes to learned embeddings: the compatibility-function family of methods (DeViSE, ALE, SJE, ESZSL, ConSE and others) that learned to score how well an image matches a class description, and the use of word vectors from unsupervised language models as a free substitute for hand-built attributes. The fourth chapter turns to geometry, the source of zero-shot learning's most persistent pathologies. It explains hubness, the tendency of a few points in high-dimensional spaces to become everyone's nearest neighbor; projection domain shift, the fact that a mapping learned on seen classes lands unseen-class inputs in the wrong places; and the remedies these problems provoked, from reversing the direction of the mapping to transductive methods that look at unlabeled test data. The fifth chapter is about evaluation, which turned out to be where much of the field's apparent progress was hiding. It explains how overlap between pretraining data and "unseen" test classes inflated results, how a 2017 reassessment proposed cleaner splits, and why the generalized setting exposed a strong bias toward seen classes that conventional evaluation had concealed. It introduces the harmonic-mean metric and calibration methods that became standard. The sixth chapter describes the generative turn: methods that use class descriptions to synthesize features for unseen classes, turning the zero-shot problem into an ordinary supervised one. It covers conditional GANs and variational autoencoders, what they fixed, and what they could not. The seventh chapter covers language at scale: contrastive vision-language pretraining, the CLIP family, prompt engineering and prompt learning, descriptions generated by large language models, and the evidence that zero-shot performance tracks pretraining frequency. The eighth chapter addresses cross-domain generalization: what happens when the inputs, not just the categories, change. It covers robustness to distribution shift, the trade-off between fine-tuning and zero-shot robustness, open-vocabulary detection and segmentation, compositional generalization, knowledge-graph methods, and zero-shot transfer in audio and scientific domains. The ninth chapter is practical. It sets out how to build and evaluate a zero-shot system responsibly: how to write class descriptions, how to calibrate, how to construct a genuinely held-out evaluation, how to detect when inputs fall outside the model's competence, and when to abandon zero-shot in favor of a handful of labeled examples. The conclusion draws out what follows from treating zero-shot generalization as borrowed: what it implies for claims about machine "understanding," which problems remain genuinely open, and what a practitioner should do differently. A note on scope The booklet concentrates on visual recognition because that is where zero-shot learning was defined, benchmarked and fought over, and because the visual-semantic bridge makes the underlying ideas concrete. It treats language models' zero-shot abilities and other modalities where they illuminate the same mechanisms, without attempting a survey of every application. It assumes no prior background in machine learning beyond a general familiarity with the idea that a model learns from labeled examples; technical terms are defined as they arise, and a glossary at the end collects the ones that recur. Chapter 1. The Problem of the Unseen Class Ordinary supervised classification makes an assumption so basic that it is rarely stated: the categories the model will be asked about at test time are the same categories it saw during training. A model trained on a thousand ImageNet classes outputs a probability distribution over those thousand classes and nothing else. Show it a photograph of an okapi, which is not among them, and it will confidently report the nearest thing it knows, perhaps a zebra or an antelope. It has no way to say "okapi," because "okapi" was never a column in its output layer. This closed-world assumption is convenient for training and disastrous for deployment. The world contains vastly more categories than any labeled dataset. The long tail is the norm: a handful of categories are common and well photographed, while thousands of others are rare. A wildlife monitoring system will encounter species nobody thought to label. A product-recognition system will meet items released after it was trained. A medical system will see presentations of disease that were absent from the training hospital. Collecting labeled examples for every category in advance is not merely expensive; it is impossible, because the categories that matter are not all known in advance. Zero-shot learning addresses a specific version of this problem. It asks how a model can recognize a category from which it has seen no labeled examples at all, given some description of that category. The description is essential. Without it, the problem is not zero-shot learning but novelty detection (recognizing that an input belongs to no known category) or clustering (grouping unlabeled inputs). Zero-shot learning promises something stronger: not just "this is new," but "this is an okapi." The anatomy of the problem It helps to state the setup precisely, because much of the field's later confusion came from imprecision about it. There are two disjoint sets of classes. The seen classes are those for which labeled training examples exist. The unseen classes are those for which none exist. Every class, seen or unseen, comes with a piece of side information, sometimes called auxiliary information or a class embedding: a vector or a structured object that describes the class in a way not derived from its training images. During training, the model has access to labeled examples from the seen classes and to the side information for the seen classes, and often for the unseen classes too. At test time, it receives an input and must assign it a label. Two test-time settings need to be distinguished. In conventional zero-shot learning, the test inputs come only from unseen classes, and the model chooses only among unseen classes. In generalized zero-shot learning, the test inputs can come from either seen or unseen classes, and the model must choose among all of them. The generalized setting is obviously the realistic one: a deployed system does not know in advance whether the thing in front of it is new. It is also much harder, for reasons that took the field several years to appreciate fully and which the fifth chapter examines. For now it is enough to notice that the conventional setting smuggles in a large piece of information, namely that the answer is guaranteed to be one of the novel classes. A model that would always prefer a familiar class can still score well when familiar classes are not on the menu. A third distinction concerns what the model may look at during training. In the inductive setting, the model sees nothing about unseen-class inputs during training; it has only their side information. In the transductive setting, the model may look at the unlabeled test inputs, all at once, before committing to predictions. Transductive methods can exploit the cluster structure of the unseen-class data, which helps considerably, but they assume that a batch of test data is available in advance, which is not always true. Mixing the two settings in a single comparison table, as was common in early papers, makes methods look better or worse than they are. Finally, there is a question about what the model has seen before training on the seen classes begins. Most zero-shot vision systems start from a feature extractor, a deep network pretrained on a large dataset such as ImageNet. If that pretraining dataset happens to contain the "unseen" classes, then the feature extractor has already learned to separate them, and the zero-shot method is being given a head start that the word "unseen" denies. This issue sounds pedantic until one discovers how often it happened, which is the subject of a later chapter. Forms of side information Side information is the far bank of the bridge. Its quality sets a ceiling on everything else, because a model cannot recognize a distinction its descriptions do not encode. Over the history of the field, side information has taken five main forms. Attributes are human-defined properties that apply to many classes: colors, shapes, textures, parts, habitats, behaviors. Each class is described by a vector saying which attributes it has, either as binary yes-or-no values or as continuous strengths averaged over annotators' judgments. Attributes are interpretable and transfer naturally, because "striped" means the same thing for a zebra as for a tiger. They are also expensive, because someone must define a vocabulary and annotate every class, and incomplete, because no finite vocabulary captures every distinction that matters. Word embeddings are vectors learned from large text corpora by models such as word2vec (2013) and GloVe (2014). Words that appear in similar contexts receive similar vectors, so "zebra" sits near "horse" and "giraffe." Using the word vector of a class name as its side information costs nothing beyond the class name itself, which made word embeddings an attractive substitute for attributes once they became available. Their weakness is that textual co-occurrence and visual similarity are different things. "Zebra" and "savanna" co-occur constantly in text but look nothing alike. Textual descriptions are sentences or paragraphs about a class: an encyclopedia entry, a field-guide description, or a set of crowd-sourced captions. They are richer than a single word and closer to how a person would explain a new category, but they need a model to turn them into vectors, and they contain a great deal of text irrelevant to appearance. Knowledge graphs and taxonomies describe classes through their relationships to other classes. WordNet, the lexical database whose noun hierarchy organizes ImageNet, places "okapi" under "giraffid," under "ruminant," and so on. A zero-shot method can propagate information along such edges: if a model knows what giraffes look like, and knows the okapi is the giraffe's closest relative, it has a starting guess for the okapi. Natural-language prompts processed by large pretrained models are the most recent form. A model such as CLIP takes a phrase such as "a photo of an okapi, a type of mammal" and produces a vector in a space it shares with images. The side information here is not a curated artifact at all but whatever the text encoder learned from hundreds of millions of image-caption pairs. It is the most flexible form and the least controllable. These forms are not mutually exclusive, and the best results have often come from combining them. But they differ in how directly they encode the visual properties that distinguish classes, how much human effort they demand, and how much they inherit the biases of whatever corpus produced them. Each later chapter can be read as a study of what one form of side information makes possible and what it leaves out. Three founding papers The idea of recognizing things from descriptions alone is old in both cognitive science and artificial intelligence. Its modern form in machine learning can be dated to three papers published within about a year of one another. In 2008, Hugo Larochelle, Dumitru Erhan and Yoshua Bengio published "Zero-data Learning of New Tasks" at the AAAI conference. Their framing was general: rather than learning a separate classifier for each task, a model could take a description of the task as input, so that a new task with a description but no training data could still be handled. They demonstrated the idea on character recognition and on molecular activity prediction, where the "description" of a class could be, for example, a rendered image of the character. The term they used, "zero-data learning," did not stick, but the core move did: treat class descriptions as inputs to the model rather than as fixed output indices. In 2009, Mark Palatucci, Dean Pomerleau, Geoffrey Hinton and Tom Mitchell published "Zero-Shot Learning with Semantic Output Codes" at NeurIPS. Their application was neural decoding: predicting which word a person was thinking about from their fMRI brain scan. Training scans existed for some words but not others. The authors proposed mapping brain activity into a semantic feature space, in which each word was described by features such as answers to questions like "Is it manmade?" or by co-occurrence statistics from a large text corpus, and then picking the word whose semantic code was nearest to the prediction. They also gave a formal analysis of when such a classifier could be expected to work: roughly, when the semantic codes for unseen classes were well separated and the mapping into semantic space was accurate enough. That analysis anticipated the controlling idea of this booklet: the semantic space must encode the distinctions that matter, and the mapping must preserve them. Also in 2009, Christoph Lampert, Hannes Nickisch and Stefan Harmeling published "Learning to Detect Unseen Object Classes by Between-Class Attribute Transfer" at CVPR. They built a dataset called Animals with Attributes, with fifty animal classes each described by eighty-five attributes, and split it into forty training classes and ten test classes with no overlap. They then trained a separate classifier for each attribute on the training classes and recognized test classes by combining attribute predictions. In the same year, Ali Farhadi, Ian Endres, Derek Hoiem and David Forsyth published "Describing Objects by Their Attributes," which argued that a recognition system should be able to say what an object is like, not just what it is called, and that doing so allowed it to say something useful about unfamiliar objects. These papers established the template the field followed for a decade. Lampert and colleagues' dataset became the field's most used benchmark. Palatucci and colleagues' structure of mapping inputs into a semantic space and then searching for the nearest class became the default architecture. And Larochelle and colleagues' insight that class descriptions should be inputs rather than indices is, in retrospect, exactly what CLIP does when it encodes the text "a photo of an okapi." Why it can work at all It is worth pausing on why zero-shot recognition is possible in principle, because the answer reveals what it depends on. A classifier trained in the ordinary way learns a function from inputs to labels, and nothing about that function says anything about labels it never saw. Zero-shot learning replaces the label with something that has internal structure. If labels are vectors in a semantic space, and if the function from inputs to that space is smooth and generalizes beyond its training points, then an input from a new class may land near that class's semantic vector even though no example of it was used to fit the function. The key word is generalizes. The function was fitted on seen classes only. For it to land unseen-class inputs in the right places, the relationship between visual appearance and semantic description must be roughly the same for seen and unseen classes. Attributes make this concrete. Suppose the seen classes include tigers, which are striped, and horses, which have hooves. A model that has learned to detect stripes from tigers and hooves from horses can, in principle, detect a striped, hoofed animal as a zebra. The knowledge transferred is knowledge about attributes, and it transfers because the attributes are shared. If the unseen class depends on an attribute no seen class had, say "has a prehensile tongue" for the okapi, the model has nothing to transfer, and that part of the description is dead weight. The same logic holds for every form of side information. Word embeddings transfer to the extent that textual similarity tracks visual similarity. Knowledge graphs transfer to the extent that taxonomic neighbors look alike. Large vision-language models transfer to the extent that the concept, or its components, appeared often enough in their training data for the text and image encoders to agree on where it belongs. In every case, zero-shot generalization is the reuse of structure learned from seen classes. The structure must be present in the semantic space, it must be shared across the seen and unseen classes, and the mapping must have learned it rather than shortcuts specific to the seen classes. This gives three ways a zero-shot system can fail, and they recur throughout the booklet. The semantic gap: the side information does not encode the distinctions needed to separate the unseen classes, or encodes distinctions that are not visible. The projection shift: the mapping, fitted only on seen classes, distorts or misplaces inputs from unseen classes. And the seen-class bias: when seen and unseen classes compete, the model systematically prefers the classes it was trained on, because its mapping was optimized to land seen-class inputs precisely on seen-class descriptions. Neighbors of zero-shot learning Several related problems share some of zero-shot learning's structure but differ in important ways, and keeping them distinct avoids confusion. Few-shot learning gives the model a small number of labeled examples, typically one to five, for each new class. It does not require side information, because the examples themselves define the class. In practice the boundary blurs: a single image of a new class is a very informative kind of side information, and many modern systems combine a text description with a handful of examples. But the two settings make different demands. Few-shot learning tests whether a model can adapt quickly from evidence; zero-shot learning tests whether it can recognize from description alone. Open-set recognition and out-of-distribution detection ask a model to recognize when an input belongs to no known class, without saying what it is. They are natural companions to zero-shot learning, because a deployed system must know when to defer, and the ninth chapter treats them as a practical necessity. But they do not name the novel class. Domain adaptation and domain generalization keep the classes fixed and change the input distribution: a model trained on product photographs must work on phone snapshots, or one trained on daytime driving must work at night. Zero-shot learning keeps the input domain roughly fixed and changes the classes. Real deployments often face both at once, and the eighth chapter is devoted to that combination. Zero-shot prompting of language models uses the term in a looser sense: the model performs a task described in natural language without examples of that task in the prompt. GPT-3's 2020 paper popularized this usage alongside "one-shot" and "few-shot," referring to the number of demonstrations given in context. The underlying mechanism is closely related to vision-language zero-shot classification, since a task description plays the role of side information, but the "classes" are often not classes at all. The shape of the decade that followed With the problem defined, the next decade's research can be summarized as successive attempts to strengthen each part of the bridge. Early work refined attribute classifiers and confronted the expense and incompleteness of attributes. A second wave replaced hand-built attributes with learned embeddings and replaced separate attribute classifiers with a single function scoring how compatible an image is with a class description. A third wave discovered that these mappings behaved badly in high-dimensional spaces and that evaluation protocols had hidden problems, and proposed fixes to both. A fourth wave sidestepped the mapping problem by synthesizing features for unseen classes. A fifth, arriving from outside the zero-shot research community, trained the bridge on internet-scale paired data and made zero-shot classification a routine capability. Each wave left something behind. The attribute literature left a vocabulary for thinking about what descriptions must contain. The embedding literature left the compatibility-function framework that CLIP still uses. The geometry literature left an understanding of hubness and shift that explains failures of modern systems. The evaluation literature left the generalized setting and the habit of asking whether "unseen" means unseen. The generative literature left the idea that descriptions can be turned into training data, now revived in systems that generate synthetic images from text. None of it has become obsolete; it has become the explanation for why the newest systems behave as they do. Chapter 2. Attributes: The First Bridge The appeal of attributes is that they make the bridge between images and categories visible. A class is described by a list of properties a person can name and check. A model learns to detect those properties from images of familiar classes. A new class is recognized by detecting its properties. Every step is inspectable: if the model calls an okapi a zebra, one can ask which attributes it detected and see where the reasoning went wrong. No later family of methods has been as transparent, and none has made the dependence of zero-shot learning on its side information so plain. Building an attribute vocabulary An attribute is a property shared across categories. The useful ones have three qualities. They are visually grounded, meaning they can in principle be detected from the input. They are discriminative across classes, meaning they split the set of categories in informative ways rather than being true of all or none. And they are transferable, meaning the visual evidence for the attribute looks roughly the same in different categories. "Striped" is a good attribute on all three counts. "Lives in Africa" is discriminative but only loosely visual. "Is endangered" is not visual at all. The benchmark datasets that defined the field each embodied a particular approach to choosing and annotating such a vocabulary. Animals with Attributes, introduced by Lampert and colleagues in 2009, drew its class-attribute matrix from earlier psychology research on how people judge the properties of animals. Its eighty-five attributes mixed color ("black," "white," "brown"), pattern ("spots," "stripes"), body parts ("hooves," "paws," "flippers," "horns"), size and shape ("big," "small," "bulbous," "lean"), behavior ("swims," "hops," "hibernates"), diet ("meat," "plankton"), habitat ("ocean," "forest," "arctic") and character ("fierce," "timid," "smart"). The values were continuous strengths averaged over human judgments, which could be thresholded to binary. The annotations were made per class, not per image: every image of a dalmatian inherited the dalmatian's attribute vector, including images where the spots were hidden. The original dataset's images were later found to have licensing problems, and in 2017 Yongqin Xian and colleagues released Animals with Attributes 2, with the same classes and attributes and 37,322 freely licensed images. Caltech-UCSD Birds-200-2011, known as CUB and described by Catherine Wah and colleagues in 2011, took the opposite approach. Its 312 binary attributes were organized around bird anatomy and field-guide terminology: the color and pattern of the crown, wing, breast, back, tail and throat; bill shape and length; wing shape; overall size. Crucially, they were annotated per image by crowd workers, then averaged into class-level vectors. That made the attributes much more closely tied to what was actually visible, and it made the dataset fine-grained: two hundred species of North American birds, many of which differ only in subtle markings. CUB later became the main testbed for methods using textual descriptions, after Scott Reed and colleagues collected ten single-sentence descriptions for each of its images in 2016. The SUN Attribute dataset, from Genevieve Patterson and James Hays in 2012, described 717 scene categories with 102 attributes covering materials ("foliage," "concrete," "water"), surface properties, functions and affordances ("sailing," "studying," "shopping"), and spatial layout ("enclosed area," "open area"). Scenes are hard to describe with attributes because many scene categories differ by function more than appearance, and with only a handful of images per class, SUN pushed methods toward very low-data regimes. Attribute Pascal and Yahoo, or aPY, came from Farhadi and colleagues' 2009 work: object categories from the PASCAL VOC challenge as seen classes and additional categories gathered from Yahoo image search as unseen classes, described by sixty-four attributes. Its unseen classes, such as "centaur," "jetski" and "zebra," were often visually distant from its seen classes, which made it a difficult and somewhat idiosyncratic benchmark. Table 1 sets these four benchmarks side by side using the class counts and splits that became standard after the 2017 reassessment discussed in the fifth chapter. Table 1. The four standard attribute benchmarks for zero-shot image classification. Dataset Domain Images Classes (seen / unseen) Attributes Annotation level AwA2 Animals 37,322 50 (40 / 10) 85 Per class, continuous CUB Bird species 11,788 200 (150 / 50) 312 Per image, averaged SUN Scene types 14,340 717 (645 / 72) 102 Per image, averaged aPY Objects 15,339 32 (20 / 12) 64 Per image Source: Xian, Lampert, Schiele and Akata, "Zero-Shot Learning — A Comprehensive Evaluation of the Good, the Bad and the Ugly" (2018 journal version). The differences in the table matter more than they first appear. AwA2 has many images per class, few classes and coarse distinctions; a decent feature extractor separates its classes almost unaided. CUB has fine distinctions and attributes designed to capture them. SUN has many classes and very few images of each. aPY has a large gap between seen and unseen classes. A method that wins on one may lose on another, and the pattern of wins and losses says something about what each method relies on. Direct and indirect attribute prediction Lampert and colleagues proposed two ways to turn attribute detectors into a zero-shot classifier, and the contrast between them captures a basic design choice. Direct Attribute Prediction, or DAP, trains one binary classifier per attribute, using all training images from seen classes. The "striped" classifier is trained on every seen-class image, each labeled positive if its class is striped (tigers, say) and negative otherwise. At test time, each attribute classifier outputs a probability that the image has its attribute. The model then scores each unseen class by how well its attribute signature matches those probabilities, in the simplest version by multiplying the probability of each attribute being present or absent as the class demands, and dividing by a prior. The class with the highest score wins. The attribute classifiers never know which class they are helping to recognize; they are general-purpose property detectors. Indirect Attribute Prediction, or IAP, trains an ordinary classifier over the seen classes. At test time, it computes the probability of each seen class, converts that into attribute probabilities by averaging the seen classes' attribute vectors weighted by those probabilities, and then scores unseen classes as DAP does. The attributes here are derived from class similarity: an image that looks seventy percent like a horse and thirty percent like a tiger is inferred to be likely hoofed and somewhat striped. DAP generally performed better, and the reason is instructive. IAP can express only attribute combinations that are mixtures of seen classes. If the seen classes include striped animals without hooves and hoofed animals without stripes, an image of a zebra might be read as halfway between them, giving moderate probabilities for both attributes rather than high probabilities for each. DAP's separate detectors can report both attributes as strongly present. DAP treats attributes as genuinely compositional; IAP treats them as properties of known classes. Zero-shot learning lives on composition. But DAP has its own weakness, which is that its attribute detectors are trained independently and assumed to be independent at test time. Neither assumption holds. Attributes co-occur in the training data: in AwA, almost every animal that "swims" is also found in "water," and almost every one with "flippers" lives in the "ocean." A "flippers" detector trained on such data may learn to detect water rather than flippers, because water is a larger, easier cue that predicts the label perfectly within the seen classes. When an unseen class breaks the correlation, the detector fails. Dinesh Jayaraman, Fei Sha and Kristen Grauman documented this problem in 2014, in a paper whose title stated the remedy: "Decorrelating Semantic Visual Attributes by Resisting the Urge to Share." They encouraged attribute classifiers to rely on different subsets of features according to semantic groupings, so that the color detectors would not borrow from the texture features, and showed better generalization when correlations shifted. The correlation problem is a specific case of the projection shift introduced in the first chapter. The mapping from images to attributes is fitted on seen classes. Wherever the seen classes contain a shortcut that predicts an attribute, the mapping learns the shortcut. Unseen classes, by definition, are where shortcuts break. What attributes cannot say Attribute-based zero-shot learning ran into four limitations that, taken together, explain why the field moved on. The first is annotation cost. Someone has to define an attribute vocabulary for each domain, and someone has to annotate every class, ideally every image. For CUB, that meant crowd workers marking 312 attributes on each of nearly twelve thousand images. This is feasible for a benchmark and impossible at the scale of ImageNet's twenty-one thousand categories, let alone open-world recognition. Worse, the vocabulary does not transfer between domains: bird attributes are useless for furniture. The second is incompleteness. Any finite vocabulary leaves out distinctions. If two unseen classes have identical or near-identical attribute vectors, no amount of modeling skill can separate them. On AwA, a few classes are distinguished mainly by attributes that are hard to see. On CUB, some species differ in features absent from the 312 attributes, such as song or subtle proportions. The ceiling on a zero-shot classifier is set by how well the attribute vectors separate the unseen classes, and that ceiling is sometimes low. The third is visual ambiguity. Many attributes are not reliably visible. "Fierce," "smart," "hibernates" and "nocturnal" describe animals well but cannot be read off a photograph. Even visible attributes depend on viewpoint and occlusion: the per-class annotation of AwA claims that every image of a deer shows hooves, but many show only a head in foliage. Per-image annotation, as in CUB, reduces the mismatch at enormous cost. The fourth is context dependence. An attribute's appearance varies with the category it applies to. "Spotted" on a dalmatian, a leopard and a ladybug involves different spot sizes, shapes and contrasts. "Has a tail" covers a peacock's train and a rat's tail. A single detector for each attribute must cover all its manifestations, and its competence on any one depends on which manifestations the seen classes happened to include. The transferability that made attributes attractive is therefore only partial. There were attempts to fix each problem. Researchers mined attributes automatically from web text: Tamara Berg, Alexander Berg and Jonathan Shih in 2010 discovered visual attributes from product descriptions, and Marcus Rohrbach and colleagues in 2010 compared semantic relatedness measures drawn from WordNet, Wikipedia and web search to transfer knowledge between classes without manual attributes at all. Devi Parikh and Kristen Grauman in 2011 introduced relative attributes, which describe classes by comparison ("bears are furrier than giraffes but less furry than rabbits") rather than by absolute presence, because people can make comparative judgments more reliably than absolute ones and comparisons carry more information. Others learned "latent" or "unnameable" attributes that were discriminative but had no human label, trading interpretability for completeness. What attributes taught the field Attributes did not survive as the dominant form of side information, but the lessons they taught have proved durable. They showed that zero-shot learning is composition. A new class is recognized by recombining pieces learned from old classes. The pieces must be shared, and the model must learn the pieces rather than the wholes. This is the same requirement that later work on compositional zero-shot learning, discussed in the eighth chapter, makes explicit by asking models to recognize unseen combinations of known states and objects such as "sliced tomato" when it has seen "sliced apple" and "ripe tomato." They showed that the side information sets the ceiling. When attribute vectors fail to separate classes, nothing downstream can recover the lost distinction. This lesson returns with CLIP-style models, where the wording of a class prompt determines which part of the text encoder's learned space the class occupies, and where descriptions that omit the distinguishing features of a class produce confusions that no amount of image-side capacity can repair. They showed that mappings learn shortcuts. Attribute detectors that were trained on correlated data learned to detect context, and failed when context changed. The same phenomenon appears in every later method, in more opaque forms. And they established interpretability as a value. A system that can say "I think this is an okapi because I see a giraffe-like body, striped legs and a short neck" is easier to debug, trust and correct than one that outputs a label with a confidence score. Recent work has returned to this idea with large language models: rather than hand-annotated attributes, a language model is asked to list the visual features of each class ("an okapi has a dark brown body, horizontal white stripes on its legs, a long neck and large ears"), and a vision-language model scores each feature against the image. Sachit Menon and Carl Vondrick showed in 2023 that classifying by such descriptors could improve accuracy and give an explanation for each decision. The attribute idea survived by finding a cheaper way to produce attributes. The step that came between, however, was to abandon interpretable attributes for learned vector spaces, in exchange for scale. That trade, and the compatibility-function framework that made it, is the subject of the next chapter. Chapter 3. Learning the Bridge: Visual-Semantic Embeddings Between roughly 2013 and 2016, zero-shot learning was transformed by two developments outside it. Deep convolutional networks, after AlexNet's win in the 2012 ImageNet challenge, produced image features far more powerful than anything hand-engineered. And neural language models, culminating in word2vec in 2013, produced word vectors that captured semantic relationships from raw text. Together they suggested a new architecture for zero-shot learning: map images and class names into a shared vector space, learned from data, and classify by proximity. The attribute vocabulary, with its annotation cost and incompleteness, could be replaced or supplemented by a space that came free with a large enough corpus. This chapter describes that architecture and the family of methods it produced. Their common element is a compatibility function: a learned score that says how well an image matches a class description. Almost every zero-shot method since, including CLIP, can be read as a particular choice of compatibility function and a particular way of training it. The compatibility function Let an image be represented by a feature vector produced by a pretrained network, typically a few thousand numbers taken from the network's penultimate layer. Let each class be represented by its side-information vector: an attribute vector, a word embedding, or an encoded description. A compatibility function takes one of each and returns a number. Classification picks the class whose description gives the highest score for the image. Because the function accepts any class description, it can score unseen classes as easily as seen ones. The simplest and most widely used compatibility function is bilinear. It multiplies the image vector by a learned matrix and takes the dot product with the class vector. Equivalently, the matrix projects the image into the semantic space (or the class vector into the image space, or both into a third space), and the score is the similarity there. The matrix is the bridge. It is learned from seen-class training data by making the correct class's score higher than the incorrect classes' scores, and at test time it is applied unchanged to unseen classes. Within this framework, methods differ along three axes: what side information they use, what objective they optimize, and which direction they project. These choices sound technical, but they determine how the bridge behaves on unseen classes. DeViSE and the move to word vectors The most influential early paper in this line was DeViSE, the Deep Visual-Semantic Embedding model, published by Andrea Frome and colleagues at Google in 2013. They took a convolutional network trained on the thousand ImageNet classes and a skip-gram language model trained on a large corpus of Wikipedia text. They replaced the network's final classification layer with a linear projection into the word-vector space and trained it so that each image's projection had a higher dot product with its class's word vector than with any other class's word vector by a margin, a so-called hinge rank loss. At test time, an image from any class could be projected into the word space and labeled with the nearest class name, including names of classes the network had never been trained on. The scale was what made DeViSE striking. Rather than ten unseen animals, it was evaluated on thousands of unseen ImageNet categories drawn from the full twenty-one-thousand-class hierarchy, sorted by how many steps away they were in WordNet from the training classes. Absolute accuracy was low, a few percent at the hardest settings, but the model's mistakes were semantically reasonable: when it was wrong, it tended to be wrong in the direction of related classes. It also showed that word vectors, which cost nothing to obtain, could stand in for attributes at a scale where annotation was out of the question. Richard Socher and colleagues published a closely related idea in the same year, "Zero-Shot Learning Through Cross-Modal Transfer," which mapped images into a word-vector space and added a step that would become important later: a novelty detector that first decided whether an image belonged to a seen or unseen class, and then routed it to the appropriate classifier. That two-stage design was an early acknowledgment of the generalized setting's difficulty. ConSE: a mapping without training A year later, Mohammad Norouzi and colleagues proposed ConSE, for Convex combination of Semantic Embeddings, which achieved comparable or better results than DeViSE with no additional training at all. ConSE took an ordinary classifier trained on the seen classes. For a test image, it took the classifier's top few predicted seen classes and their probabilities, and formed a weighted average of those classes' word vectors. The unseen class whose word vector was nearest to that average was the prediction. ConSE is the embedding-space analog of Indirect Attribute Prediction from the previous chapter: it describes a new image as a mixture of known classes, and then asks which unseen class's description is closest to that mixture. It works well when unseen classes are genuinely intermediate between seen ones, and it inherits IAP's limitation when they are not. Its success was a useful reminder that the elaborate machinery of learned projections was not always necessary. A pretrained classifier already contains a great deal of semantic structure in its output probabilities, and a good semantic space can exploit it directly. The structured-prediction family A cluster of methods from 2013 to 2016 refined the bilinear compatibility function by importing ideas from structured prediction and ranking. Attribute Label Embedding, or ALE, from Zeynep Akata, Florent Perronnin, Zaid Harchaoui and Cordelia Schmid (first presented in 2013 and published in fuller form in 2016), treated the class's attribute vector as its label embedding and learned the bilinear matrix with a ranking objective weighted so that errors at the top of the ranking mattered most. ALE showed that attribute-based zero-shot learning could be cast as learning a compatibility function rather than training independent attribute classifiers, which removed DAP's independence assumption and allowed attributes to be weighed jointly. Structured Joint Embedding, or SJE, by Akata, Scott Reed, Daniel Walter, Honglak Lee and Schiele in 2015, used a structured support-vector-machine loss and, importantly, combined multiple sources of side information: attributes, word2vec and GloVe embeddings of class names, and WordNet hierarchy embeddings. It found that attributes, where available, remained the strongest single source on fine-grained datasets such as CUB, but that combining sources helped, and that unsupervised embeddings were respectable substitutes when attributes were not available. Embarrassingly Simple Zero-Shot Learning, or ESZSL, from Bernardino Romera-Paredes and Philip Torr in 2015, did exactly what its name promised. It wrote the problem as regularized least squares: find the matrix that best maps image features to class similarities, with penalties on the norms of the projected images and projected class descriptions. The solution has a closed form, which can be computed in a few lines of linear algebra with no iterative training. ESZSL matched or beat more elaborate methods on the benchmarks of the day, and it remained a strong baseline for years. Its success suggested that much of the reported progress came from better features and careful regularization rather than from sophisticated objectives. Latent Embeddings, or LatEm, by Xian and colleagues in 2016, replaced the single bilinear matrix with several, letting each image select the most compatible one. This allowed the compatibility function to be piecewise linear, capturing the idea that different visual aspects (color, shape, pose) might relate to the semantic space through different mappings. Synthesized Classifiers, or SynC, by Soravit Changpinyo, Wei-Lun Chao, Boqing Gong and Fei Sha in 2016, took a different perspective. Rather than projecting images into the semantic space, it introduced a set of "phantom" classes in both spaces and expressed each real class's classifier as a combination of phantom classifiers, with the weights determined by semantic similarity. A new class's classifier could then be synthesized from its description. This made explicit the idea that zero-shot learning predicts classifiers, not just labels, an idea that had appeared earlier in work such as Mohamed Elhoseiny, Babak Saleh and Ahmed Elgammal's 2013 "Write a Classifier," which predicted a visual classifier from a Wikipedia article, and Jimmy Lei Ba and colleagues' 2015 work predicting the weights of a deep network's output layer from textual descriptions. What the side information actually contributes The embedding-alignment era produced a reasonably clear answer to a question the attribute era could only pose: how much do the different forms of side information actually contribute? Attributes, when carefully designed for a domain, were consistently the best single source. On CUB, attribute-based methods outperformed word-vector methods by large margins. The reason is that the attributes were chosen to capture the visual distinctions between bird species, whereas word vectors for species names capture whatever textual contexts those names appear in. The word vector for "Laysan albatross" reflects where the phrase occurs in Wikipedia or news text, not the bird's dark back and white underside. Rare class names are worse still, since their word vectors are estimated from few occurrences and are noisy. Word vectors were nonetheless indispensable at scale, because they were the only source available for thousands of categories. And they captured a coarse taxonomic structure that was genuinely useful: animals near animals, vehicles near vehicles, musical instruments near musical instruments. Textual descriptions offered a middle path. Reed and colleagues' 2016 paper "Learning Deep Representations of Fine-Grained Visual Descriptions" collected ten sentences per CUB image ("this bird has a white belly, a black crown and a short pointed bill") and trained character-level and word-level text encoders jointly with the image encoder, so that the text side was learned rather than fixed. With enough descriptions, learned text representations approached and in some settings exceeded the performance of the hand-designed attributes. The text encoder was effectively extracting the attributes from free-form language. Wikipedia articles, used in work by Elhoseiny and others, were richer but noisier. An article about a bird species discusses its range, breeding behavior, conservation status and taxonomy, much of which is irrelevant to appearance. Methods that used them had to learn to attend to the visual sentences and ignore the rest. The pattern is the one the first chapter predicted. Side information works to the extent that it encodes visual distinctions. Curated attributes encode them deliberately. Descriptions written by people looking at images encode them almost as well. Generic text encodes them only incidentally. The direction of the bridge One technical choice in this family turned out to be far more consequential than anyone initially realized. DeViSE and most of its successors projected images into the semantic space and searched for the nearest class there. This seems natural: the semantic space is where class descriptions live, so that is where the comparison should happen. But the semantic space is usually lower-dimensional than the image feature space, and projecting high-dimensional image features into it with a regression objective has a characteristic side effect. The projections shrink toward the mean, and some class vectors become the nearest neighbor of a disproportionate number of projected images. The model ends up predicting a small number of "hub" classes for almost everything. This hubness problem, and the closely related problem that projections learned on seen classes land unseen-class images in the wrong regions, dominated the next phase of research. They are not quirks of particular methods but consequences of the geometry of high-dimensional spaces and of fitting a mapping on one set of classes and applying it to another. Understanding them requires stepping back from the methods to look at the space itself, which is the business of the next chapter. The legacy of the compatibility framework Before moving on, it is worth stating plainly how much of this framework survives in current systems. CLIP's classification rule is a compatibility function: the cosine similarity between an image embedding and a text embedding, with both encoders trained jointly. Its training objective is a ranking loss over a batch, pushing each image's matched caption above the mismatched ones, which is a direct descendant of DeViSE's hinge rank loss. Its side information is encoded text, as in Reed and colleagues' work. What it adds is scale, and the decision to learn both sides of the bridge from scratch on paired data rather than fixing one side as pretrained word vectors. The compatibility framework's central insight was that a zero-shot classifier does not need a fixed output layer. It needs a way to score any (input, description) pair. Once that insight was established, the remaining questions were about what spaces to use, how to train the scoring function, and how to stop it from failing in the ways the next chapter describes. Chapter 4. The Geometry of Failure: Hubness, Shift and the Semantic Gap By 2015, the embedding approach had a recognizable shape and a recognizable set of failures. Models mapped images into a semantic space and picked the nearest class. On unseen classes, they made errors that were not random. A few classes absorbed a large share of predictions. Images from one unseen class were systematically placed near another. Some pairs of classes were indistinguishable however the model was trained. These errors had structural causes rooted in the geometry of high-dimensional spaces and in the logic of fitting a mapping on one set of classes and applying it to another. Understanding them is the most useful thing a reader can take from the pre-CLIP literature, because the same structures are present in today's systems, usually hidden by scale rather than removed. Hubness: why some points are everyone's neighbor In a low-dimensional space, such as points scattered on a page, every point is roughly as likely as any other to be the nearest neighbor of some query. In high-dimensional spaces this stops being true. Miloš Radovanović, Alexandros Nanopoulos and Mirjana Ivanović described the phenomenon systematically in a 2010 paper titled "Hubs in Space." They counted, for each point in a dataset, how many other points listed it among their k nearest neighbors. In low dimensions, the counts were spread evenly. As the dimension grew, the distribution became heavily skewed: a few points, the hubs, appeared in the neighbor lists of a very large number of others, while many points, the anti-hubs, appeared in almost no one's list. The cause is the concentration of distances. In high dimensions, distances between random points become nearly equal, so small differences in position have large effects on rankings. Points that happen to lie closer to the center of the data distribution are slightly closer to everything, and that slight advantage translates into being the nearest neighbor of a disproportionate share of queries. Hubness is not a defect of particular data; it is a property of high-dimensional nearest-neighbor search. For zero-shot learning, hubness has a direct and damaging consequence. Classification by nearest class vector is nearest-neighbor search, with projected images as queries and class descriptions as the database. If a few class vectors are hubs, they will be predicted for a large fraction of test images regardless of what those images show. Accuracy collapses not because the model cannot tell classes apart in principle, but because its decision rule is dominated by a few points' geometry. How regression makes hubness worse The embedding methods of the previous chapter made hubness worse in a specific and predictable way. Most of them learned a linear map from image features to semantic vectors by minimizing squared error between projected images and their class vectors, usually with regularization. Regression of this kind has a well-known property: its outputs have lower variance than its targets. When the relationship between inputs and outputs is noisy, the least-squares solution hedges toward the mean, and regularization pushes further in the same direction. The projected images therefore cluster more tightly around the center of the semantic space than the class vectors do. Two papers in 2015 traced the consequences. Georgiana Dinu, Angeliki Lazaridou and Marco Baroni showed that when cross-space mappings were learned by regression, the mapped vectors exhibited strong hubness, and proposed a correction: rather than picking the nearest class for each image, they normalized each class's similarity scores by how similar that class was to a large pool of other mapped vectors, penalizing classes that were close to everything. In a companion paper, Lazaridou, Dinu and Baroni argued that replacing the squared-error objective with a max-margin ranking objective reduced the shrinkage and hence the hubness, because a ranking loss cares only about relative order and does not reward hedging toward the mean. Yutaro Shigeto and colleagues, in a 2015 paper titled "Ridge Regression, Hubness, and Zero-Shot Learning," gave an analysis of why shrinkage causes hubs and proposed a strikingly simple fix: reverse the direction of the mapping. Instead of projecting images into the semantic space, project class descriptions into the image feature space. The argument runs as follows. Hubness among database items arises when queries are shrunk toward the center, because then whichever database items lie nearest the center become neighbors of everything. If instead the shrunk vectors are the database (the projected class prototypes) and the queries (the test images) keep their natural spread, the database items lose their central advantage, and hubness diminishes. On standard benchmarks, this reversal improved accuracy substantially with no other change. Li Zhang, Tao Xiang and Shaogang Gong made a similar argument in 2017, proposing that the visual feature space should be the embedding space, with a neural network mapping semantic descriptions into it. They noted an additional benefit: the visual space produced by a deep network trained on many classes is already well structured for discriminating images, so placing class prototypes into it lets the classifier exploit that structure rather than compressing it away. The lesson extended beyond zero-shot learning. In 2018, Alexis Conneau and colleagues confronted the same problem when mapping word vectors between languages to build bilingual dictionaries without parallel data. Their solution, Cross-domain Similarity Local Scaling or CSLS, adjusted each similarity score by subtracting the average similarity of each point to its nearest neighbors in the other space, so that hub points were penalized and isolated points were boosted. The technique is directly applicable to zero-shot classification and has been used there. Modern contrastive models reduce hubness in part by normalizing all embeddings to unit length and comparing by cosine similarity with a learned temperature, which removes the variance-shrinkage pathway, but hubness has not disappeared from them; it has been documented in CLIP-style retrieval, where some images or captions are retrieved far more often than chance would predict. Projection domain shift Hubness is a property of the space. A second failure arises from the logic of training. The mapping from images to semantic vectors is fitted on seen classes only. Nothing guarantees that it will behave the same way on unseen classes, and there are strong reasons to expect it will not. Yanwei Fu, Timothy Hospedales, Tao Xiang and Shaogang Gong named this the projection domain shift problem in work published in 2014 and 2015. Consider the attribute "has a tail." Seen classes in an animal dataset might include zebras, horses and pigs, whose tails are visually quite different. A mapping trained on them learns some combination of visual features that predicts "has a tail" for those animals. An unseen class, say a pig-like animal with a very different tail, might map to a point with only a weak tail score, even though the attribute vector says the tail is present. The mapping's notion of "tail" was shaped by the seen classes, and the unseen class's tails fall outside it. Multiply that effect across all attributes, and the projected images of an unseen class end up displaced from the class's true description, often closer to some other class's description. Fu and colleagues visualized this displacement and found that projected unseen-class images often formed tight clusters that were simply in the wrong place: coherent as a group, but offset from where their class descriptions said they should be. That observation suggested a remedy. If the test images of each unseen class form a cluster, and the cluster structure is visible in the unlabeled test data, then one can adjust either the projection or the class prototypes to align clusters with descriptions. This is the transductive approach. Fu and colleagues projected both images and descriptions into a shared space using multiple views (attributes and word vectors together) and then propagated labels over a graph built from the unlabeled test data. Elyor Kodirov, Tao Xiang, Zhenyong Fu and Shaogang Gong in 2015 framed the problem as unsupervised domain adaptation, refining the unseen-class prototypes using the test data's structure. Transductive methods produced large gains on benchmarks. Their weakness is the assumption that a batch of unlabeled test data is available in advance and contains a reasonable number of examples per unseen class. A system that must classify each image as it arrives cannot use them directly, though it can sometimes approximate them by accumulating test data over time. An alternative, inductive response to projection shift is to regularize the mapping so that it cannot discard information unseen classes might need. Kodirov, Xiang and Gong's 2017 Semantic Autoencoder, or SAE, did this by requiring that the projection from image features to semantic vectors be invertible in a weak sense: the semantic vector, projected back by the transposed matrix, should reconstruct the original image features. A mapping that must reconstruct its input cannot collapse visual information that does not happen to matter for the seen classes, because reconstruction penalizes the loss. The result was a mapping that generalized better to unseen classes, with a closed-form solution as simple as ESZSL's. The idea that a mapping should preserve information beyond what training classes require recurs throughout later work, including the reconstruction losses in generative methods discussed in the sixth chapter. The semantic gap The third failure is the most basic and the least fixable by modeling: the side information does not encode what the images show, or encodes things the images do not show. A word vector for "killer whale" may sit closer to "shark" than to "dolphin" because of how the words appear in text, even though killer whales look much more like dolphins. Attribute vectors for "deer" and "moose" may differ mainly in "big," a relative judgment poorly captured from a single photograph. A Wikipedia article for a bird species may devote three paragraphs to range and diet and one sentence to plumage. In each case the semantic space has a structure, but it is not the structure of visual similarity. The mapping can learn to align the two spaces where they agree, but where they disagree, no mapping can reconcile them without distorting one or the other. This is the semantic gap: the mismatch between how classes are related in the semantic space and how they are related in the visual space. It explains a pattern visible throughout the empirical literature. Methods using carefully designed attributes beat methods using word vectors on fine-grained data, because the attributes were designed to close the gap. Methods that learn the text encoder jointly with the image encoder, as Reed and colleagues did and as CLIP does, beat methods with fixed text representations, because joint training reshapes the semantic space to match visual similarity. And methods that combine several forms of side information tend to beat any single one, because each source closes different parts of the gap. There is a deeper version of the semantic gap that no amount of joint training closes. Some distinctions between classes are not visual at all. Two species of bird may be distinguished mainly by their songs, two mushrooms by spore color under a microscope, two pills by their chemical composition. A visual zero-shot system cannot recognize such classes from images, whatever its side information says, because the evidence is not in the input. This seems obvious stated plainly, but zero-shot benchmarks do contain such cases, and a system that reports confident predictions on them is reporting noise. Knowing which distinctions are visually supported is part of designing a zero-shot task honestly. Seen-class bias as a geometric problem The three failures above concern the conventional setting, where only unseen classes are candidates. In the generalized setting, a fourth failure dominates, and it has a geometric explanation as well. The mapping was trained to land seen-class images precisely on their class vectors. For seen classes, the projections are accurate and tightly clustered. For unseen classes, projections are displaced by domain shift and blurred by the mapping's imperfect generalization. When a test image from an unseen class is projected, it often lands nearer to some seen class's vector than to its own class's vector, simply because seen-class vectors are where the mapping was trained to send things. When seen and unseen classes compete, seen classes win far more often than they should. Wei-Lun Chao, Soravit Changpinyo, Boqing Gong and Fei Sha measured this in 2016 and found that accuracy on unseen classes collapsed when seen classes were added as candidates, often to a small fraction of its conventional-setting value. Their remedy, which they called calibrated stacking, subtracts a constant from every seen class's score before choosing the maximum. Varying the constant traces out a curve from "always predict seen classes" to "always predict unseen classes," and choosing a point on the curve sets the trade-off. The method is simple, but its effectiveness made a point the field needed to hear: much of the gap between conventional and generalized performance came not from an inability to recognize unseen classes, but from a systematic bias in how scores for seen and unseen classes compared. The fifth chapter returns to this in the context of evaluation. What the geometry teaches The failures described here are not historical curiosities. Every zero-shot system has a semantic space, a mapping into it and a decision rule over it. In high-dimensional spaces, nearest-neighbor decision rules produce hubs unless corrected. Mappings fitted on some classes are displaced on others. Semantic spaces built from text encode textual structure, which overlaps imperfectly with visual structure. And mappings trained on seen classes favor those classes when they compete with new ones. Scale changes the magnitudes. A model trained on hundreds of millions of image-text pairs has seen so many classes that the distinction between "seen" and "unseen" becomes blurred, which reduces projection shift for common concepts. Contrastive training with normalized embeddings reduces regression shrinkage. Joint training of text and image encoders narrows the semantic gap. But for concepts that are rare in the training data, for distinctions that text rarely discusses, and for deployments where familiar and novel categories compete, the old geometry reasserts itself. A practitioner who sees a vision-language model predicting the same handful of labels for most of a dataset, or consistently confusing two classes whose names are textually similar, is looking at hubness and the semantic gap. The geometric failures were real, and remedies for them produced genuine gains. But by 2017 it was becoming clear that a large part of the field's reported progress had another source entirely: the way methods were being evaluated. Chapter 5. How Unseen Is Unseen? The Evaluation Reckoning A zero-shot result is a claim that a model recognized something it had never been shown. The claim is only as good as the guarantee that it had never been shown it. For most of the field's first decade, that guarantee was weaker than anyone acknowledged, and the generalized setting that would have exposed the weakness was rarely reported. When both problems were addressed, a great deal of apparent progress turned out to be an artifact of how methods had been tested. The episode is worth understanding in detail, both because it changed how zero-shot learning is evaluated and because the same issue has reappeared, in a larger and harder form, with internet-scale models. The pretraining leak By the mid-2010s, almost every zero-shot image classifier used image features extracted from a deep convolutional network pretrained on ImageNet's thousand-class subset, the ILSVRC dataset with about 1.28 million labeled images. That network was trained to discriminate a thousand categories, and its features are strongly tuned to separate them. Zero-shot methods then learned a mapping from these features to attributes or word vectors using the seen classes of a benchmark, and tested on the unseen classes. The problem is that the unseen classes of the standard benchmarks were not unseen by the feature extractor. ImageNet's thousand classes include dozens of animal species. Several of the ten unseen classes in the original Animals with Attributes split were among them, and the same was true for some unseen classes in the other benchmarks. A feature extractor trained to separate those classes from each other with labeled examples had already done much of the work the zero-shot method claimed to do. The "zero-shot" mapping only had to find, in a feature space already organized around the test classes, a way to connect each cluster to its description. That is a far easier task than recognizing a genuinely novel category. Yongqin Xian, Bernt Schiele and Zeynep Akata set out to measure the effect in a 2017 CVPR paper, expanded with Christoph Lampert into a 2018 journal article whose title signaled its tone: "Zero-Shot Learning — A Comprehensive Evaluation of the Good, the Bad and the Ugly." They re-implemented a dozen prominent methods under a single protocol, using the same ResNet-101 features for all of them, and proposed new splits for the four standard benchmarks in which no unseen class appeared among ImageNet's thousand training classes. On these proposed splits, accuracy on unseen classes generally fell, sometimes sharply, and the ranking of methods changed. Methods that had looked superior on the old splits were not always superior on the clean ones. The paper identified other problems as well. Different papers had used different image features, different numbers of training classes, different attribute normalizations and different accuracy measures, making published numbers incomparable. Some had tuned hyperparameters using the test classes, which leaks information in a subtler way: choosing the regularization strength that works best on the unseen classes is a form of training on them. And many reported accuracy averaged over test images rather than over classes, which rewards methods that do well on the most populous unseen classes and conceals failures on smaller ones. The proposed protocol fixed a disjoint set of validation classes, carved out of the seen classes, for hyperparameter tuning, and reported per-class average accuracy so that every class counted equally. None of this implied bad faith. Each choice had seemed reasonable at the time. But the cumulative effect was a literature in which numbers had drifted away from the capability they were supposed to measure. The generalized setting and the harmonic mean The second and larger part of the reckoning was the shift to the generalized setting. As described in the first chapter, conventional zero-shot evaluation tests only on unseen-class images and asks the model to choose only among unseen classes. This removes from consideration the very classes a model trained on seen classes is most inclined to predict. Chao and colleagues' 2016 study, mentioned in the previous chapter, was among the first to measure what happened when that restriction was lifted. Xian and colleagues adopted the generalized setting as a core part of their protocol. The test set contained held-out images from seen classes and all images from unseen classes, and the model chose among all classes. They reported accuracy on seen-class test images and on unseen-class test images separately. The results were sobering. Methods that achieved respectable accuracy on unseen classes in the conventional setting saw that accuracy collapse in the generalized setting, often to single digits and in some cases to near zero, while their accuracy on seen classes stayed high. The models were not failing to tell unseen classes apart from each other. They were failing to choose unseen classes at all when seen classes were available, because seen-class scores were systematically higher. To summarize performance in one number, Xian and colleagues proposed the harmonic mean of seen and unseen accuracy: twice their product divided by their sum. The harmonic mean is high only when both accuracies are high. A model with ninety percent seen accuracy and two percent unseen accuracy has an arithmetic mean of forty-six percent, which sounds respectable, but a harmonic mean of about four percent, which correctly reports that the model is useless for recognizing new things. The harmonic mean became the headline metric of generalized zero-shot learning, and it remains so on the classic benchmarks. Chao and colleagues proposed a complementary measure. Since calibrated stacking introduces a constant that trades seen accuracy against unseen accuracy, one can sweep the constant across its range and plot unseen accuracy against seen accuracy. The area under the seen-unseen accuracy curve, or AUSUC, summarizes performance across all trade-offs rather than at a single operating point. A model with a higher AUSUC is better at separating the two kinds of class regardless of how one sets the bias. The two metrics answer different questions: the harmonic mean asks how well the model performs as deployed, and AUSUC asks how much discriminative capacity the model has before calibration. Why calibration works, and what it reveals The effectiveness of calibrated stacking deserves more attention than its simplicity might suggest. Subtracting a single constant from all seen-class scores is about the crudest correction imaginable. It does not change the model's ranking among seen classes or among unseen classes; it only shifts the boundary between the two groups. Yet it often produced dramatic improvements in the harmonic mean. This reveals something important about where the generalized setting's difficulty lies. If a single scalar offset can recover much of the lost unseen accuracy, then the model's representations already contain most of the information needed to recognize unseen classes. What they lack is a correct comparison between the confidence of a seen-class prediction and the confidence of an unseen-class one. The seen-class scores are inflated because those classes were trained on. The problem is calibration, not discrimination. That diagnosis motivated several families of solutions. Gating or novelty-detection methods, extending Socher and colleagues' 2013 design, first decide whether a test image belongs to a seen or unseen class and then route it to a specialized classifier. Generative methods, covered in the next chapter, synthesize unseen-class training data so that a single classifier is trained on both kinds of class and has no reason to prefer either. Temperature scaling and other calibration techniques adjust the sharpness of each group's score distribution. And transductive methods use unlabeled test data to estimate how often unseen classes appear and adjust accordingly. The same diagnosis applies, with modification, to large vision-language models. When CLIP is asked to choose among a set of labels, some labels are systematically favored because their text embeddings sit in favorable positions in the shared space, or because their names were frequent in pretraining. Those are calibration failures, and simple corrections that adjust each label's prior can produce substantial gains, an observation formalized in several recent papers on calibrating zero-shot classifiers. The large-scale benchmarks Alongside the four attribute benchmarks, a large-scale evaluation built on the full ImageNet hierarchy was used, following DeViSE. The training classes were ImageNet's thousand ILSVRC classes, and the test classes were drawn from the roughly twenty-one thousand classes of the full ImageNet. Test sets were defined by distance in the WordNet hierarchy: the "2-hop" set contained unseen classes within two steps of a training class, the "3-hop" set those within three steps, and the "all" set contained every remaining class. Later protocols added sets defined by how many images each class had, distinguishing well-populated classes from rare ones. Side information was the word vector of each class name, since no attributes existed at that scale. Absolute accuracies on these benchmarks were low, in single digits for the larger test sets, and the gains reported by new methods were often a fraction of a percentage point. Xian and colleagues' reassessment found that these benchmarks too had problems, including noisy and ambiguous class names in the wider ImageNet hierarchy and inconsistent use of the test sets across papers. But they were the only available test of whether zero-shot methods worked at anything like realistic scale, and their low numbers were an honest signal of how far the field was from open-world recognition before vision-language pretraining. A taxonomy of protocols By the end of the 2010s, the combination of settings described in this chapter and the first had produced several distinct evaluation protocols, each answering a different question. Table 2 lays them out, because confusing them was the source of many misleading comparisons. Table 2. Common zero-shot evaluation protocols and what each one measures. Protocol Test images from Candidate labels Unlabeled test data at training? Typical headline metric Conventional, inductive Unseen classes only Unseen only No Per-class top-1 accuracy Conventional, transductive Unseen classes only Unseen only Yes Per-class top-1 accuracy Generalized, inductive Seen and unseen All classes No Harmonic mean of seen and unseen accuracy Generalized, transductive Seen and unseen All classes Yes Harmonic mean Large-scale hierarchy (ImageNet-21K) Classes at set WordNet distances Test-set classes, optionally plus seen No Top-k accuracy (flat hit at k) Vision-language "zero-shot transfer" Any downstream dataset That dataset's labels No Top-1 accuracy per dataset The last row deserves comment. When CLIP and its successors report "zero-shot" accuracy on ImageNet, they mean that the model was not fine-tuned on ImageNet's training set and received only the class names. They do not mean that the model had never seen images of those classes; its pretraining data almost certainly contained many. In the terms of this chapter, vision-language zero-shot transfer is closer to the conventional setting with a leaky feature extractor than to the clean generalized protocol. Its authors were explicit about this; the original CLIP paper described its evaluation as a test of task transfer rather than of recognition of truly novel concepts, and it included an analysis of overlap between its pretraining data and evaluation datasets. But the word "zero-shot" carries the older meaning with it, and readers sometimes hear more than is claimed. The recurring question The evaluation reckoning of 2017 was, at bottom, a reminder that zero-shot generalization must be borrowed from somewhere, and that one must account honestly for where. A feature extractor pretrained on the test classes lends its knowledge to the zero-shot mapping. Hyperparameters tuned on test classes lend information about them. A conventional evaluation lends the knowledge that the answer is novel. Each loan inflates the result above what the side information and mapping alone would achieve. The proposed splits and the generalized protocol cleaned up the classic benchmarks, and subsequent work on them is far more comparable as a result. But the larger lesson did not stay learned. A few years later, models trained on hundreds of millions of web images arrived, and the question "has the model seen this class?" became nearly impossible to answer by inspection, because no one could list everything in the training set. The seventh chapter returns to this question and to recent attempts to answer it by measuring how often each concept appears in pretraining data. Before that, though, the field took one more major turn, and it was motivated directly by the seen-class bias this chapter exposed: if the classifier prefers seen classes because it was trained only on them, why not give it training data for the unseen classes too? Chapter 6. Imagining the Unseen: Generative Approaches The seen-class bias described in the last chapter has a simple root. A classifier trained only on seen classes has a lopsided view of the world: it knows in detail what seen-class images look like and knows about unseen classes only through their descriptions. When the two compete, detailed knowledge wins. Calibration can compensate for the lopsidedness after the fact. The generative approach removes it at the source. If a model can turn each unseen class's description into plausible training examples, then an ordinary classifier can be trained on real examples of seen classes and synthetic examples of unseen ones, and it has no reason to favor either. Zero-shot learning becomes supervised learning with imagined data. From descriptions to features The idea of synthesizing training data for unseen classes was explored in several forms before 2018, but it took off with a specific design choice: generate image features, not images. In 2017 and 2018, image generation from text was still crude. Generative adversarial networks could produce small, blurry images of birds or flowers from descriptions, but those images were not good enough to train a classifier. Generating feature vectors, the few-thousand-dimensional outputs of a pretrained network's penultimate layer, was far easier. The features lie in a lower-dimensional space than pixels, are already organized for discrimination, and need only be good enough to place class boundaries correctly, not to look realistic to a person. The influential paper was "Feature Generating Networks for Zero-Shot Learning" by Yongqin Xian, Tobias Lorenz, Bernt Schiele and Zeynep Akata, published at CVPR in 2018. Its model, called f-CLSWGAN, was a conditional Wasserstein GAN. A generator network took a class's attribute vector and a random noise vector and produced a synthetic feature vector. A critic network took a feature vector and an attribute vector and tried to tell real (feature, class) pairs from generated ones. The two were trained adversarially on seen classes, so that the generator learned to produce features that matched the distribution of real features for each class description. A third term, a classification loss from a classifier pretrained on seen classes, pushed generated features to be discriminative: not merely realistic, but recognizable as belonging to their intended class. After training, the generator was fed the descriptions of unseen classes, producing hundreds or thousands of synthetic features per class. A plain softmax classifier was then trained on the union of real seen-class features and synthetic unseen-class features. At test time, this classifier labeled real images from both kinds of class. The effect on generalized zero-shot learning was large. On CUB under the proposed splits, the reassessment described in the previous chapter had reported a harmonic mean of 34.4 for ALE, one of the strongest compatibility-function methods, with seen accuracy of 62.8 and unseen accuracy of 23.7. f-CLSWGAN reported a harmonic mean of 49.7, with unseen accuracy rising to 43.7 and seen accuracy falling only to 57.7. The pattern was similar on the other benchmarks. The improvement came almost entirely from unseen accuracy, exactly where the bias had been costing the most. Variational autoencoders and aligned latent spaces GANs are notoriously unstable to train and prone to mode collapse, in which the generator produces only a narrow range of outputs for each condition. For zero-shot learning, mode collapse means that the synthetic features of an unseen class cluster too tightly, and the classifier learns a boundary that excludes much of the class's real variability. Several groups turned to variational autoencoders, which trade some sharpness for stable training and better coverage. Ashish Mishra and colleagues, and separately Vinay Kumar Verma and colleagues, proposed conditional variational autoencoders for zero-shot learning in 2018. An encoder mapped a real feature and its class description to a latent code; a decoder mapped a latent code and a class description back to a feature. After training on seen classes, sampling latent codes from the prior and decoding them with an unseen class's description produced synthetic features for that class. Xian and colleagues combined the two families in 2019 with f-VAEGAN-D2, which used a VAE's encoder-decoder structure for stable coverage and a GAN's critic for sharpness, and added a second critic that operated on unlabeled features. That second critic let the model use unlabeled test data when it was available, making the same architecture usable in both inductive and transductive settings. Edgar Schönfeld, Sayna Ebrahimi, Samarth Sinha, Trevor Darrell and Zeynep Akata took a different route in 2019 with CADA-VAE, for Cross- and Distribution-Aligned VAE. Rather than generating features in the visual space, they trained two VAEs, one on image features and one on class descriptions, and forced their latent spaces to align: the latent code of an image should be decodable into its class description, the latent code of a description should be decodable into an image feature, and the latent distributions of matching pairs should be close. Classification then happened in the shared latent space, with unseen-class training points obtained by encoding their descriptions. This blurred the boundary between generative and embedding approaches. The model learned a joint space, like the compatibility methods of the third chapter, but it learned it by reconstruction and distribution matching rather than by ranking. Other work explored cycle consistency, requiring that a synthetic feature mapped back to the semantic space should recover the description that generated it, an idea related to the semantic autoencoder of the fourth chapter. Yizhe Zhu and colleagues in 2018 generated features from noisy Wikipedia text rather than attributes, showing that the generative approach could work with cheaper side information, though at a cost in accuracy on fine-grained benchmarks. What generation fixes, and what it cannot The generative approach addressed the seen-class bias directly and effectively. A classifier trained on balanced real and synthetic data does not prefer seen classes by construction. Generators also mapped from the semantic space to the visual space, the reverse of most early embedding methods, which the fourth chapter showed reduces hubness. Several of the old pathologies were addressed at once. But the generative approach cannot escape the controlling constraint of zero-shot learning. A generator is itself a mapping from descriptions to features, trained only on seen classes. Everything it knows about how descriptions relate to appearance, it learned from seen classes. When it receives an unseen class's description, it produces features by extrapolating that relationship. If the relationship differs for unseen classes, the synthetic features are displaced, exactly as projected images were displaced in the embedding methods. Projection domain shift does not disappear; it moves from the classifier into the generator. Nor can a generator create information that the description lacks. If two unseen classes have nearly identical attribute vectors, the generator will produce nearly identical feature distributions for them, and the downstream classifier will be unable to separate them. The semantic gap remains exactly as wide as before. Generation converts description into data, but the data contains no more distinguishing information than the description did. Generated features are also characteristically too clean. A generator trained to match seen-class feature distributions learns their typical spread, but real unseen-class images may vary in ways seen classes did not: unusual poses, backgrounds or lighting associated with a particular species. The classifier trained on synthetic data learns a boundary that fits the generator's idea of the class rather than the class's real extent. Several papers addressed this by regularizing generators toward diversity, by refining real and synthetic features jointly, or by combining generation with transductive use of test data, but the problem is intrinsic to extrapolation from seen classes. Finally, generative methods introduce choices with large effects and little principled guidance: how many synthetic features to generate per class, how to balance real and synthetic data in the final classifier, how to weight the classification and adversarial losses. Reported results are sensitive to these choices, and comparisons across papers again became difficult as methods multiplied. Table 3 summarizes how the major method families of the pre-CLIP era stand in relation to the failures traced through the preceding chapters. Table 3. Pre-CLIP zero-shot method families compared against the main failure modes. Family Representative methods Hubness Projection shift Seen-class bias (generalized setting) Interpretability Attribute classifiers DAP, IAP Low exposure (no embedding search) High; correlated attributes break Severe High Image-to-semantic embedding DeViSE, ALE, SJE, ESZSL High under regression High Severe Low to moderate Semantic-to-image embedding Shigeto et al., Zhang et al. Reduced High Severe Low Reconstruction-regularized SAE Moderate Reduced Severe Low Transductive Fu et al., Kodirov et al. Reduced Reduced using test clusters Moderate Low Feature generation f-CLSWGAN, CVAE, f-VAEGAN-D2, CADA-VAE Reduced Moved into generator Largely addressed Low The table's message is that each family fixed something specific, and none fixed the semantic gap, because no method downstream of the side information can. Generation in the age of diffusion The generative idea has had a second life with the arrival of high-quality text-to-image models. Diffusion models such as Stable Diffusion, released in 2022, can produce photorealistic images from short text prompts. That makes it possible to do what was impractical in 2018: generate actual images, not features, for any class with a name, and train an ordinary image classifier on them. Several studies tested this directly. Ruifei He and colleagues, in a 2023 ICLR paper asking whether synthetic data from generative models was ready for image recognition, generated images of each target class from text prompts and used them to improve zero-shot and few-shot classification with CLIP, finding meaningful gains, particularly when the prompts were diversified with language-model assistance and the synthetic images were filtered for quality. Mert Bülent Sarıyıldız and colleagues in the same year trained classifiers on synthetic ImageNet clones generated entirely from class names and found that they learned surprisingly transferable representations, while still falling short of training on real images. These results confirm both halves of the generative lesson. Turning descriptions into data works, and it removes the bias of training only on familiar classes. But the generated images can contain only what the generator knows about each class, and the generator learned that from its own training data, which is again a corpus of captioned web images. A text-to-image model that has rarely seen a particular species will produce generic or wrong images of it, and a classifier trained on those images will inherit the errors. The generalization is still borrowed, now from the generator's pretraining corpus rather than from attribute annotations. There is a further subtlety. Diffusion models and contrastive vision-language models are often trained on overlapping web data, and many diffusion models use a CLIP text encoder to interpret their prompts. A pipeline in which one model generates training images and another, trained on similar data, is evaluated on them risks circularity: the classifier learns to recognize what the generator thinks a class looks like, which may be close to what the classifier already thought. Gains from such pipelines are real on benchmarks, but they should be read as reorganizing knowledge already present in pretraining data rather than adding new knowledge about the world. The turn away from benchmarks By 2020, the generative approach had pushed harmonic-mean scores on the classic benchmarks considerably higher, and incremental papers continued to refine generators, losses and feature-refinement schemes. But the field's center of gravity was about to shift. The classic benchmarks used a fixed feature extractor pretrained on ImageNet and side information from attributes or word vectors. A different research program, pursued at large industrial laboratories, was asking a different question: what would happen if both the image encoder and the text encoder were trained from scratch, jointly, on hundreds of millions of image-text pairs collected from the web? The answer, delivered in 2021, changed what "zero- shot" meant in practice. Chapter 7. Language at Scale: Contrastive Pretraining and the New Zero-Shot In January 2021, OpenAI published "Learning Transferable Visual Models From Natural Language Supervision," by Alec Radford, Jong Wook Kim and colleagues, introducing a model called CLIP, for Contrastive Language-Image Pre-training. Its architecture was not new in principle. An image encoder and a text encoder each produced a vector; the two vectors were compared by cosine similarity; the encoders were trained so that matching image-text pairs scored higher than mismatched ones. This is the compatibility-function framework of the third chapter, trained with a ranking objective descended from DeViSE's. What was new was the data and the decision to learn both sides of the bridge from scratch. CLIP was trained on about four hundred million image-text pairs gathered from the internet, with no manual labels at all. The result recast zero-shot learning. A model that had never been trained on ImageNet's labeled images could classify them by encoding each class name in a sentence such as "a photo of a goldfinch" and choosing the sentence whose embedding was closest to the image's. CLIP's largest model reached 76.2 percent top-1 accuracy on ImageNet this way, matching the original ResNet-50, which had been trained on ImageNet's 1.28 million labeled images. Across a suite of twenty-seven datasets, zero-shot CLIP outperformed a fully supervised linear classifier trained on ResNet-50 features on sixteen. For the first time, zero-shot classification was competitive with supervised training on a broad range of real tasks. This chapter explains how contrastive pretraining works, why it succeeded where earlier methods had struggled, how the wording of class descriptions became a new and powerful lever, and why the generalization it delivers is, like everything before it, borrowed. How contrastive training builds the bridge The training procedure is simple to state. Take a batch of image-text pairs, tens of thousands at a time; CLIP used batches of 32,768. Encode every image and every text. Compute the cosine similarity between every image and every text in the batch, giving a square table of scores in which the diagonal entries are the true pairs. Train both encoders so that each image's true caption has the highest score in its row and each caption's true image has the highest score in its column, using a softmax cross-entropy loss over each row and column with a learned temperature. This is a form of the InfoNCE contrastive loss. Several features of this setup address problems the earlier chapters described. Both encoders are trained, so the semantic space is reshaped to match visual similarity rather than being fixed by a text corpus, closing much of the semantic gap that afflicted word-vector methods. Embeddings are normalized to unit length and compared by cosine similarity, which removes the variance-shrinkage pathway through which regression created hubs. The objective ranks rather than regresses, which Lazaridou and colleagues had argued reduces hubness. And the "classes" during training are not a fixed list but the open-ended space of things people write in captions, so the model is never trained to favor a particular set of labels over others. Most important, the scale of the data changes what "seen" means. In the classic benchmarks, a model trained on forty animal species was tested on ten others. CLIP was trained on captions mentioning a vast range of objects, scenes, styles, activities, places and people. Almost any class name a user is likely to try has appeared in its training data, often thousands of times, attached to images of the thing it names. The zero-shot classifier is not extrapolating from forty species to ten; it is retrieving knowledge it acquired from millions of weakly labeled examples, using the class name as the query. Other laboratories quickly confirmed and extended the approach. Google's ALIGN, by Chao Jia and colleagues in 2021, trained a similar dual-encoder model on about 1.8 billion image and alt-text pairs with minimal filtering and found that scale compensated for noise. Xiaohua Zhai and colleagues' LiT in 2022 showed that one could freeze a strong pretrained image encoder and train only the text side, an echo of the older practice of using fixed ImageNet features. CoCa, by Jiahui Yu and colleagues in 2022, added a captioning objective to the contrastive one and pushed zero-shot ImageNet accuracy considerably higher. SigLIP, from Zhai and colleagues in 2023, replaced the softmax over the batch with an independent sigmoid loss on each pair, making training more efficient at large and small batch sizes alike. Open efforts mattered as much as industrial ones: the LAION project released datasets of hundreds of millions and then billions of image-text pairs, and the OpenCLIP project trained and released models on them, allowing independent researchers, including Mehdi Cherti and colleagues in a 2023 study of scaling laws, to study how performance grows with data, model size and compute. Wording as a lever: prompt engineering A dual-encoder classifier has a property the attribute-based systems lacked: its side information is natural language, and any phrasing of a class can be tried. The CLIP authors discovered quickly that phrasing mattered a great deal. The simplest issue was that captions are sentences, not bare words. Using the bare class name as the text input underperformed using it inside a template such as "a photo of a {label}." The CLIP paper reported that this template alone improved ImageNet accuracy by 1.3 percentage points. A second issue was ambiguity. ImageNet contains both "crane" the bird and "crane" the construction machine; the Oxford-IIIT Pets dataset contains "boxer" the dog breed, which a text encoder might read as an athlete. Adding context, as in "a photo of a {label}, a type of pet," resolved such cases. Domain-specific templates helped too: "a satellite photo of a {label}" for remote sensing images, "a photo of a {label}, a type of food" for a food dataset. The authors then found that averaging the text embeddings of many templates for each class, "a photo of a big {label}," "a blurry photo of a {label}," "a drawing of a {label}" and so on, worked better still. Ensembling eighty templates improved ImageNet accuracy by a further 3.5 points over the single default template, and together prompt engineering and ensembling gained almost five points. Since the ensemble is computed once per class in text-embedding space, it adds no cost at test time. Prompt ensembling is a form of the multi-source side information that SJE had explored with attributes and word vectors: each template contributes a slightly different view of the class, and their average is more robust than any one. It also exposes the fragility of the bridge. A five-point swing from rewording is larger than many of the gains reported by method papers on the classic benchmarks. If a model's competence on a class depends that much on the exact words used to name it, the model's notion of the class is entangled with linguistic surface form in ways a person's is not. Prompt learning and the return of base and novel classes If wording matters so much, perhaps the best wording can be learned. Kaiyang Zhou, Jingkang Yang, Chen Change Loy and Ziwei Liu proposed Context Optimization, or CoOp, in 2021 (published in 2022). CoOp replaced the hand-written words of the template with a small number of learnable vectors in the text encoder's input embedding space, then trained those vectors on a few labeled examples per class while keeping both encoders frozen. With as few as sixteen examples per class, learned prompts substantially outperformed hand-crafted ones on the training classes. But CoOp exposed an old problem in a new form. When the same researchers evaluated the learned prompts on classes not seen during prompt training, performance fell below that of the hand-crafted prompts. The learned context vectors had overfit to the training classes, becoming specialized for them at the expense of generality. To measure this, the authors introduced a base-to-novel evaluation, splitting each dataset's classes in half, training prompts on the base half and testing on the novel half, and reporting the harmonic mean of base and novel accuracy. This is the generalized zero-shot protocol of the fifth chapter, reinvented for the foundation-model era, with the harmonic mean doing exactly the same job of exposing bias toward the training classes. Their follow-up, Conditional Context Optimization or CoCoOp, published at CVPR in 2022, made the learned prompt depend on each input image through a small network, which improved generalization to novel classes considerably. A large literature followed, adapting visual prompts, text prompts, adapter layers and lightweight fine-tuning, nearly all of it evaluated on the base-to-novel protocol. The recurring finding is the one the classic literature established: any adaptation fitted on some classes tends to favor them, and methods must be designed and evaluated specifically to resist that tendency. Descriptions from language models A different way to improve the text side is to say more about each class. Rather than "a photo of a hen," one can write "a hen, which has a small red comb, a plump body and short legs." Writing such descriptions by hand for thousands of classes is laborious, but large language models can generate them. Sachit Menon and Carl Vondrick's 2023 paper, "Visual Classification via Description from Large Language Models," asked GPT-3 to list the visual features useful for identifying each class, scored each feature separately against the image with CLIP, and averaged the scores. The method improved accuracy on ImageNet and several other datasets, and it produced an explanation for each prediction: a list of the features the model judged present. Sarah Pratt and colleagues' CuPL, for "Customized Prompts via Language models," published in the same year, generated many descriptive sentences per class and averaged their embeddings, also improving accuracy across a range of datasets. This is the attribute idea of the second chapter, reborn. A language model plays the role of the annotators who built the AwA attribute matrix, and a vision-language model plays the role of the attribute detectors. The cost of producing attributes falls to nearly nothing, and the vocabulary is no longer fixed in advance. A sobering control followed. Karsten Roth and colleagues, in a 2023 paper titled "Waffling Around for Performance," replaced the language-model descriptions with random words and random character sequences appended to the class name, and found that this recovered much of the accuracy gain. Part of the benefit of description ensembles, in other words, came not from their visual content but from the ensembling itself, from averaging many slightly perturbed embeddings of the class name. The authors were careful to say that semantically meaningful descriptors still helped in some settings, especially when they disambiguated classes or supplied higher-level concepts. But the result is a reminder that improvements attributed to the content of side information should be tested against controls that remove the content while keeping the form. The question the first chapter posed, whether the side information actually encodes the distinctions that matter, applies to text generated by language models just as it applied to attributes. The modality gap One geometric oddity of contrastive models is worth knowing about, because it bears on how their zero-shot predictions behave. Weixin Liang and colleagues showed in 2022, in a paper titled "Mind the Gap," that in CLIP and similar models the image embeddings and text embeddings do not mix in the shared space. They occupy two separate regions, narrow cones on the unit sphere offset from each other. Every image is closer to every other image than to any text, and vice versa. The authors traced this to a combination of how deep networks initialize their outputs and how the contrastive loss with a low temperature preserves the offset. For zero-shot classification, the gap means that similarity scores between an image and class texts are all compressed into a narrow range, and small differences in where class texts sit within the text cone have large effects on which class wins. This is a setting in which the hubness and calibration issues of the fourth and fifth chapters reappear: some class prompts are systematically favored because of their position in the text cone rather than their relevance to the image. Simple corrections, such as centering embeddings or adjusting each class's score by its average similarity to a set of unrelated images, can help, and they are direct descendants of the hubness corrections proposed for word-vector methods a decade earlier. How zero-shot is zero-shot? The deepest question about vision-language zero-shot classification is the one the fifth chapter raised about the classic benchmarks, now at a scale where it cannot be settled by inspecting a class list. CLIP was not trained on ImageNet's labels, but its pretraining data contained many images of goldfinches captioned with the word "goldfinch." In what sense is recognizing a goldfinch zero-shot? Two lines of work have sharpened the answer. Alex Fang and colleagues showed in 2022 that CLIP's celebrated robustness to distribution shift, its tendency to lose less accuracy than ImageNet-trained models when moving from ImageNet to sketches, renditions or harder photographs, came from the diversity of its training data rather than from the use of language supervision or the contrastive objective. Models trained on the same data with ordinary labels instead of captions were comparably robust. The language interface made zero-shot classification possible, but the generalization came from what the model had seen. More directly, Vishaal Udandarao and colleagues, in a 2024 paper titled "No 'Zero-Shot' Without Exponential Data," measured how often each concept from a wide range of downstream tasks appeared in the pretraining datasets of several dozen vision-language models, and compared that frequency with the models' zero-shot accuracy on the concept. Across models, datasets and tasks, they found a log-linear relationship: zero-shot performance improved roughly linearly as concept frequency grew exponentially. To gain a fixed amount of accuracy on a concept required multiplying its frequency in the training data. Concepts in the long tail, which appear rarely, were recognized poorly. The authors released a benchmark of such long-tail concepts, which they named Let It Wag!, on which leading models performed markedly worse than on standard benchmarks. These findings do not mean that vision-language models merely memorize. They generalize across viewpoints, styles and contexts in ways no memorizing system could, and they can recognize combinations of familiar elements that never co-occurred in training. But the evidence supports the controlling idea of this booklet in its strongest form. Zero-shot recognition in these models is the use of knowledge acquired from data that included the concept, accessed through a language interface. The model's competence on a concept is roughly as good as the data's coverage of that concept. Where coverage is thin, so is competence, and the long tail of the real world is exactly where coverage is thinnest. The parallel in language models Large language models showed an analogous ability in text, and it has the same structure. Tom Brown and colleagues' 2020 GPT-3 paper popularized the term "zero-shot" for performing a task from a natural-language instruction with no examples in the prompt. Earlier, Wenpeng Yin, Jamaal Hay and Dan Roth had proposed in 2019 to perform zero-shot text classification by treating it as textual entailment, asking a model trained on inference datasets whether a text entails a hypothesis such as "This text is about sports," which allowed classification into arbitrary label sets described in words. Instruction tuning, introduced in work such as Jason Wei and colleagues' 2022 paper "Finetuned Language Models Are Zero-Shot Learners," trained language models on many tasks phrased as instructions and found that this improved their ability to follow instructions for tasks held out of training. The held-out-task evaluations in that work, which removed entire task clusters from training to test transfer to them, are the language-model counterpart of the clean splits proposed by Xian and colleagues for image classification. And the same caution applies. A language model's "zero-shot" competence on a task reflects how much related material appeared in its pretraining corpus, and contamination of benchmarks by pretraining data has become a central concern in evaluating language models, for exactly the reason the pretraining leak mattered for attribute benchmarks. Multimodal language models, which accept images and text and generate text in response, now perform zero-shot classification by being asked what an image shows. They inherit both the strengths and the dependencies described in this chapter: their visual encoders are often CLIP-style models, and their competence on a category tracks its representation in their training data. The next chapter turns from the question of which categories a model can recognize to a different one: what happens when the inputs themselves change, so that a model must recognize both new categories and familiar ones in unfamiliar domains. Chapter 8. Beyond the Benchmark: Generalizing Across Domains, Tasks and Modalities The classic zero-shot problem held the input domain fixed and changed the classes: the test images were photographs of animals, like the training images, but of different species. Real deployments rarely offer that courtesy. A model trained on web photographs is asked to classify sketches, satellite images, microscope slides, infrared frames from a trail camera or product shots under a warehouse's fluorescent lights. It is asked not only to name an image but to find and outline every instance of a described object within it. It is asked to recognize combinations of familiar concepts it never saw together. And the same bridge-building logic is applied to sounds, molecules and video. This chapter examines how zero-shot methods behave when the domain, the task or the modality changes, and why the answer keeps returning to the same place: the model generalizes as far as its paired training data reaches. Distribution shift and effective robustness The machine-learning community has studied the effect of changing input distributions for decades, but a set of benchmarks built around ImageNet made the problem concrete for modern image classifiers. Each keeps ImageNet's classes, or a subset of them, and changes the images. Table 4 summarizes the most widely used. Table 4. Distribution-shift benchmarks built on ImageNet classes. Benchmark What changes relative to ImageNet Test images Classes Introduced ImageNetV2 New photographs collected by the original procedure 10,000 1,000 Recht et al., 2019 ImageNet-Sketch Black-and-white sketches About 50,000 1,000 Wang et al., 2019 ImageNet-R Renditions: paintings, cartoons, embroidery, toys, tattoos 30,000 200 Hendrycks et al., 2021 ImageNet-A Real photographs that standard classifiers get wrong 7,500 200 Hendrycks et al., 2021 ObjectNet Objects in unusual poses, backgrounds and viewpoints About 50,000 313 (113 shared with ImageNet) Barbu et al., 2019 Source: the papers cited in the final column. The striking finding from these benchmarks was how regular the losses were. Rohan Taori and colleagues showed in 2020 that, across hundreds of ImageNet-trained models, accuracy on a shifted dataset was very nearly a linear function of accuracy on ImageNet itself. Better models were better on shifted data, but they lost roughly the same proportion of their accuracy when the distribution changed, and almost no intervention, including data augmentation and most robustness techniques, moved a model off the line. The authors defined effective robustness as the amount by which a model's shifted accuracy exceeded what the line predicted from its in-distribution accuracy. CLIP was the first family of models to move well off that line. The original paper reported that zero-shot CLIP models lost far less accuracy on ImageNet-R, ImageNet-Sketch and ObjectNet than ImageNet-trained models of the same ImageNet accuracy, closing much of the robustness gap. As the previous chapter noted, Fang and colleagues later traced this to the diversity of CLIP's training data, which includes sketches, paintings, cartoons and oddly posed objects as a matter of course. A model that has seen renditions of a goldfinch with the word "goldfinch" attached is not generalizing across domains when it recognizes a cartoon goldfinch; it is applying knowledge from a domain it has already seen. The fine-tuning dilemma The robustness of zero-shot CLIP created a dilemma. Fine-tuning CLIP on ImageNet's labeled training set raised its ImageNet accuracy considerably, but it lowered its accuracy on the shifted benchmarks, sometimes below the zero-shot model's. The fine-tuned model moved back toward the line that ImageNet-trained models occupied. Gaining in-distribution accuracy cost out-of-distribution robustness. Mitchell Wortsman and colleagues proposed a disarmingly simple remedy in a 2022 CVPR paper, "Robust Fine-Tuning of Zero-Shot Models." Their method, WiSE-FT, for weight-space ensembling, takes the zero-shot model's weights and the fine-tuned model's weights and averages them, with a mixing coefficient. Because both models start from the same pretrained weights, their parameters lie in a connected region where interpolation produces a working model. The interpolated model kept most of the fine-tuned model's in-distribution gains while recovering much of the zero-shot model's robustness, and at intermediate mixing coefficients it often beat both endpoints on shifted data. Ananya Kumar and colleagues gave a complementary analysis the same year in "Fine-Tuning Can Distort Pretrained Features and Underperform Out-of-Distribution." They argued that fine-tuning the whole network with a randomly initialized classification head distorts the pretrained features in the directions that help the training distribution, damaging their usefulness elsewhere. Training the classification head first with the features frozen, and only then fine-tuning everything, reduced the distortion. The dilemma is the generalized zero-shot problem from the fifth chapter in a different guise. Adapting a model to a specific set of examples makes it better on those examples and their distribution and worse elsewhere, because the adaptation encodes features specific to the training data. Weight interpolation and staged fine-tuning are calibrations of how far to move away from the broadly trained starting point, just as calibrated stacking is a calibration of how much to favor seen classes. Where the data does not reach The same CLIP paper that reported strong zero-shot results on photographs of everyday objects also reported where they failed. Zero-shot CLIP did poorly on satellite image classification (EuroSAT), on detecting metastatic tissue in lymph-node slides (PatchCamelyon), on counting objects in synthetic scenes (CLEVR Counts), on distinguishing fine-grained types of aircraft and car models, and even on handwritten digit classification (MNIST), where it trailed simple supervised baselines. The authors noted that these were tasks underrepresented in web images and their captions, or tasks such as counting whose answers captions rarely state. The response from specialized fields has been to build the bridge again with domain-specific paired data. In pathology, Zhi Huang and colleagues trained a model called PLIP in 2023 on pathology images and descriptions collected from medical discussions on social media, and reported improved zero-shot classification of tissue types over general-purpose CLIP. Later pathology models trained on much larger collections of image-caption pairs from educational material and the biomedical literature pushed further. BiomedCLIP, from Sheng Zhang and colleagues, was trained on figure-caption pairs extracted from millions of biomedical research articles. Similar efforts have produced vision-language models for remote sensing, trained on satellite imagery paired with descriptive text. These domain models confirm the controlling idea from the other direction. A general model fails in a specialized domain because its paired data did not include enough of that domain. A specialized model succeeds within the domain because its paired data did. Zero-shot generalization across domains is not a property a model acquires by being large or by being trained with language; it is a property of the data it was given. Cross-domain transfer happens where paired data spans the domains, and fails where it does not. Open-vocabulary detection and segmentation Image classification assigns one label to a whole image. Detection and segmentation find and outline each object, which is far more useful for most applications and far more expensive to annotate. Labeling bounding boxes for every object in an image takes much longer than assigning an image-level label; labeling pixel-precise masks takes longer still. Detection datasets therefore cover far fewer categories than classification datasets: the widely used COCO dataset has eighty, and the larger LVIS dataset has about twelve hundred, of which several hundred are rare, with only a handful of training examples each. Open-vocabulary detection aims to detect objects described by arbitrary text, including categories with no box annotations at all. The standard evaluation, on LVIS, holds out the box annotations for its rare categories during training and measures detection accuracy on them, a direct transposition of the seen-unseen split. The leading methods combine a detector trained on box annotations for a limited set of categories with the open vocabulary of a vision-language model. Alireza Zareian and colleagues proposed one early version in 2021, pretraining a visual backbone on image-caption pairs before training the detector. Xiuye Gu and colleagues' ViLD, published in 2022, distilled CLIP's image embeddings into the region features of a detector: for each proposed region, the detector was trained so that its region embedding matched CLIP's embedding of the cropped region, so that at test time any category's text embedding could be used to classify regions. Matthias Minderer and colleagues' OWL-ViT, also from 2022, took a simpler path, attaching lightweight box-prediction and classification heads to a pretrained CLIP-style vision transformer and fine-tuning on detection data, yielding a detector that accepted either text queries or example images. Liunian Harold Li and colleagues' GLIP reformulated detection as phrase grounding, the task of locating the image region referred to by each phrase in a caption, which allowed training on large amounts of image-caption data with automatically generated boxes. Grounding DINO, by Shilong Liu and colleagues in 2023, combined a strong transformer-based detector with grounded pretraining and became a widely used open-set detector. Segmentation followed the same path. Boyi Li and colleagues' LSeg, from 2022, trained an image encoder to produce per-pixel embeddings aligned with CLIP's text embeddings, so that any category name could be used to segment an image. Other methods generated class-agnostic mask proposals and classified each mask with CLIP. Open-vocabulary detection and segmentation reproduce every phenomenon from the earlier chapters. Detectors trained on a limited set of box-annotated categories favor those categories at test time, the seen-class bias of the generalized setting. Rare categories, whose names appear infrequently in captions, are detected poorly, as the frequency analysis of the previous chapter would predict. The wording of category queries changes results, and prompt ensembling helps. And the detector's region features, fitted on base categories, are displaced for novel ones, a form of projection shift that distillation from CLIP partly corrects by pulling region features toward a space trained on broader data. Compositional generalization A different kind of novelty arises when a model knows all the parts of a concept but has never seen them together. A model that has seen "sliced apples" and "whole tomatoes" should recognize "sliced tomatoes." This is compositional zero-shot learning, and it tests the claim from the second chapter that zero-shot recognition is composition. Ishan Misra, Abhinav Gupta and Martial Hebert framed the problem for visual recognition in a 2017 paper titled "From Red Wine to Red Tomato: Composition with Context." They argued that attributes and objects do not compose independently: "red" looks different on wine, tomatoes and cars, so a model must learn how each attribute transforms each object rather than learning a single "red" detector. Benchmarks for this setting include MIT-States, from Phillip Isola, Joseph Lim and Edward Adelson in 2015, with images labeled by state-object pairs such as "melted chocolate" or "rusty bike," and UT-Zappos, with shoe images labeled by material and type. Later benchmarks such as C-GQA expanded the vocabulary. Evaluation splits hold out certain combinations while including their parts in training, and the generalized setting, in which both seen and unseen combinations are candidates, is standard. Large vision-language models were expected to excel at composition, since captions are full of attribute-object combinations. The evidence is mixed. Tristan Thrush and colleagues' Winoground benchmark, from 2022, presented pairs of images and pairs of captions that used the same words in a different order, such as "some plants surrounding a lightbulb" and "a lightbulb surrounding some plants," and asked models to match them. Contrastive models performed close to chance. Mert Yuksekgonul and colleagues argued in 2023 that contrastive vision-language models often behave like "bags of words," largely insensitive to word order and to which attribute attaches to which object, and traced this partly to the contrastive objective, which can be satisfied on typical batches without attending to such distinctions. Training with deliberately constructed hard negatives, captions with swapped attributes or reordered relations, improved compositional sensitivity. Compositional generalization is the case in which "borrowed" generalization is most obviously insufficient. A model can recognize "sliced tomato" if it has learned how slicing transforms objects in general and has seen enough tomatoes. If it has learned only that the words "sliced" and "tomato" both appear in the caption, it cannot distinguish a sliced tomato from a whole tomato beside a sliced apple. Composition requires that the shared structure the model borrows be the right structure: not co-occurrence of parts, but how parts combine. Knowledge graphs and structured side information The forms of side information discussed so far are attributes, word vectors and text. A fourth form, knowledge graphs, was explored intensively in the late 2010s and remains useful where taxonomies are reliable. Xiaolong Wang, Yufei Ye and Abhinav Gupta proposed in 2018 to use a graph convolutional network over the WordNet hierarchy to predict a visual classifier for each class. Each node in the graph, representing a class, began with the word embedding of its name. The network passed information along the graph's edges, and was trained so that, for seen classes, its output at each node matched the weights of that class's classifier in a pretrained CNN. For unseen classes, the network's output became a predicted classifier. On the large-scale ImageNet-21K zero-shot benchmarks described in the fifth chapter, this approach substantially improved over word-vector methods. Michael Kampffmeyer and colleagues refined it in 2019, observing that deep graph convolutions blurred the information of distant nodes together, and proposing a dense propagation scheme that connected each node directly to its ancestors and descendants. Knowledge graphs encode a particular kind of structure, taxonomic proximity, and their value depends on whether taxonomic neighbors look alike. In biology, they often do, which is why graph methods worked well on ImageNet's animal-heavy hierarchy. For manufactured objects, where WordNet's hierarchy reflects function more than appearance, the benefit is smaller. Graph structure has also been combined with vision-language models, for example by using a class hierarchy to construct prompts that include a class's parent category, which helps disambiguate rare class names. Other modalities The bridge-building recipe transfers directly to other kinds of input. Benjamin Elizalde and colleagues' CLAP, published in 2023, applied contrastive language-audio pretraining to pairs of audio clips and text descriptions, enabling zero-shot classification of environmental sounds by comparing an audio clip with text such as "the sound of a dog barking." Video models extended CLIP to clips, enabling zero-shot recognition of actions described in text, with the familiar difficulties: actions are defined by motion over time, and captions rarely describe motion precisely. In the sciences, the term "zero-shot" is used in a related but distinct sense. Protein language models trained on large collections of protein sequences can be used to score the effect of mutations on protein function without training on any labeled mutation data, by comparing the likelihood the model assigns to the mutated and original sequences; Joshua Meier and colleagues demonstrated this in 2021. Here the side information is not a description at all but the statistical structure of evolution as captured in sequence data. The logic is nevertheless the same: knowledge acquired from a large unlabeled or weakly labeled corpus is applied to a new prediction task, and it works to the extent that the corpus encodes the structure the task needs. Recommendation systems face an analogous cold-start problem when new items or users arrive without interaction histories, and they address it by describing new items through content features, text or metadata, then mapping those descriptions into the same space as items with histories. The structure of the solution, a shared space and a mapping trained on items with data, is the zero-shot bridge under another name. The common thread Across domains, tasks and modalities, the same pattern holds. A zero-shot system generalizes along the dimensions its paired training data spanned. CLIP is robust to sketches because its data included sketches. It fails on pathology slides because its data included few, and a pathology model trained on pathology captions succeeds. Open-vocabulary detectors find rare objects poorly because rare objects are rare in captions. Contrastive models compose poorly because their objective could be satisfied without composition. Graph methods help where taxonomy tracks appearance. None of this diminishes what these systems do. Generalizing along every dimension one's data covers is an enormous capability, and the dimensions covered by billions of captioned images are vast. But it means the question to ask of any zero-shot deployment is concrete: along which dimensions does my use case differ from the data the model learned from, and does the model's data span those differences? The final chapter turns that question into practice. Chapter 9. Building Zero-Shot Systems That Hold Up The preceding chapters traced a single idea through two decades of research: a zero-shot system recognizes new categories by borrowing structure from a semantic space and a mapping trained on other categories, and it fails where the semantic space lacks the needed distinctions, where the mapping misplaces new inputs, or where familiar categories crowd out unfamiliar ones. This chapter turns that idea into practice. It is addressed to someone who must build or evaluate a system that recognizes things no one has labeled for it: a wildlife team sorting camera-trap images, a retailer tagging new products, a content-moderation team adding a policy category, a clinic screening for a rare finding. In nearly every such case today, the starting point is a pretrained vision-language model or a multimodal language model, and the questions are how to use it well and how to know whether it is working. Start with the coverage question Before writing a single prompt, ask whether the model's training data is likely to span your problem. The seventh chapter showed that zero-shot accuracy on a concept tracks how often the concept appears in pretraining data, and the eighth showed that cross-domain transfer happens only where paired data spans the domains. Both findings convert into concrete checks. The first check is about your categories. Are they things people photograph and caption on the public web? Common animals, foods, vehicles, landmarks, household objects and broad scene types are heavily covered. Specialized product codes, rare species, internal defect categories, medical findings and fine-grained distinctions that only experts make are covered thinly or not at all. If your category names would look unfamiliar to a well-read generalist, expect weak zero-shot performance. The second check is about your images. Do they look like web photographs? Camera-trap frames taken at night in infrared, grayscale microscope slides, satellite tiles, thermal images, industrial line-scan images and medical scans all differ from typical web images in ways that the model's training data may not cover. Even a well-covered category can be recognized poorly in an uncovered imaging domain. The third check is about the distinction itself. Is the difference between your categories visible in the image, and is it the kind of difference captions describe? Captions name objects, describe scenes and mention salient attributes. They rarely state counts, precise sizes, subtle textures, spatial relations or the absence of something. A task that hinges on "three or more items," "a hairline crack" or "the left valve, not the right" asks for information captions seldom provide. When the answer to all three checks is favorable, zero-shot classification with a strong vision-language model can be remarkably good and is the right place to start. When any answer is unfavorable, zero-shot results should be treated as a baseline to beat, and resources should go early to collecting a small labeled set, considering domain-specific models, or both. Writing class descriptions The side information in a modern zero-shot system is the text you write for each class, and it sets the ceiling on performance just as attribute vectors did. Several practices are well supported by evidence. Use templates, not bare names. A sentence that resembles a caption, such as "a photo of a {class}," consistently outperforms the bare class name, as the CLIP authors found. Adapt the template to the imaging domain: "a camera-trap photo of a {class}," "a close-up photo of a {class} on a white background," "a satellite image of {class}." Disambiguate. Class names that are polysemous or uncommon should carry context. "Crane, a type of bird" and "crane, a construction machine" will not be confused; "crane" alone may be. Including the parent category ("a photo of a kinkajou, a type of mammal") helps for rare names whose text embeddings may be poorly estimated, a cheap version of the knowledge-graph methods of the previous chapter. Ensemble. Average the text embeddings of several templates for each class. The gains reported in the original CLIP work came at no test-time cost. Ensembles of descriptive sentences, whether written by hand or generated by a language model, can help further, especially when they describe the visual features that separate confusable classes. Test against controls. When an elaborate description scheme improves accuracy, check how much of the gain survives replacing the descriptions with meaningless variations of the class name, as Roth and colleagues did. If most of it survives, the benefit came from ensembling, not content, and simpler prompts may serve equally well. Describe the differences, not the class. For confusable pairs, the most useful text names what distinguishes them. A description of a crow that would also describe a raven adds little; one that mentions the crow's squared tail and the raven's wedge-shaped tail, if those features are visible in your images, adds what matters. This is the lesson of attribute design from the second chapter: side information should encode the distinctions the task needs. Keep a held-out set for prompt choices. Choosing templates and descriptions by trying them on your test data is the hyperparameter-tuning leak of the fifth chapter. Set aside a small validation set, ideally covering different classes from your test set if you want to estimate performance on genuinely new classes, and make prompt decisions there. Calibrate, and correct for priors Zero-shot classifiers are poorly calibrated out of the box. Their scores are cosine similarities divided by a temperature fixed during pretraining, and the resulting probabilities reflect the model's training distribution rather than yours. Some classes will be systematically favored because their text embeddings sit in advantageous positions or their names were frequent in pretraining. The fourth and fifth chapters explained why this happens; the practical remedies follow from those explanations. Inspect the prediction histogram. Run the model over a sample of unlabeled images from your deployment and count how often each class is predicted. If a few classes absorb a share far beyond their plausible frequency, you are seeing hubness or prior bias. This diagnostic needs no labels and catches the most damaging failures early. Adjust class priors. A simple correction subtracts from each class's score an estimate of its average score over a reference set of unlabeled images, or reweights predictions so that the predicted class distribution matches a known or estimated target distribution. Both are descendants of the hubness corrections of the fourth chapter and the calibrated stacking of the fifth. Tune the temperature for probabilities you will use. If downstream decisions depend on the classifier's confidence, for instance routing low-confidence cases to a human, fit a temperature on labeled validation data so that predicted probabilities match observed accuracy. Handle familiar and new classes together deliberately. If your system combines categories the model was fine-tuned on with categories it must handle zero-shot, the generalized setting's bias applies in full. Measure accuracy on each group separately, report their harmonic mean, and calibrate the offset between them, exactly as Chao and colleagues did for the classic benchmarks. Know when to abstain A zero-shot classifier forced to choose among a fixed list of labels will always choose one, even when the image shows none of them. In a closed benchmark this does not matter; in deployment it is often the most consequential failure. A wildlife classifier given a photograph of a hiker will name an animal. A product tagger given a photograph of a shipping label will name a product. Three defenses are available, and they work best in combination. Include explicit catch-all classes. Adding text classes such as "an empty scene," "a person," "a blurry image" or "something else" gives the model somewhere to put inputs that match none of the target classes. This is crude, and the catch-all classes are themselves subject to bias, but it is cheap and often effective. Threshold on similarity, not just on rank. The raw cosine similarity between an image and its best-matching class carries information about how well the image matches any class at all. Images whose best similarity is unusually low relative to a validation distribution are candidates for abstention. Because of the modality gap discussed in the seventh chapter, absolute similarity values occupy a narrow range and must be thresholded relative to observed distributions, not by intuition. Use dedicated out-of-distribution detection. A literature on detecting inputs that fall outside a model's competence has developed alongside zero-shot learning, and several methods have been adapted to vision-language models, including methods that compare an image's similarity to the target classes with its similarity to a large set of unrelated concepts. Where errors are costly, an explicit detector is worth its complexity. Evaluate as if your claims will be tested The evaluation reckoning of the fifth chapter offers a checklist for anyone reporting zero-shot results, whether in a paper or a project review. Ask what "unseen" means for your model. For a model trained on public web data, your categories may well have appeared in pretraining. That does not invalidate a zero-shot result, but it changes its meaning. If the goal is to estimate performance on future categories that will be genuinely novel or rare, construct an evaluation from categories you have reason to believe are underrepresented, such as specialized product types or uncommon species, rather than from familiar ones. Report per-class accuracy. Averaging over images rewards performance on common classes and hides failures on rare ones, which are usually the classes that motivated a zero-shot approach. Use the generalized setting when deployment is generalized. If your system will see both familiar and unfamiliar categories, evaluate it on both together and report the harmonic mean alongside each component. Separate decisions from test data. Choose prompts, thresholds, calibration parameters and model variants on validation data. Touch the test set once. Test across the shifts you expect. If your deployment includes different cameras, lighting, seasons or sites, construct test subsets that isolate each and report results separately. Aggregate accuracy can conceal a collapse on one subset that matters. Compare against a few-shot baseline. A zero-shot result is most informative when set beside what a handful of labeled examples per class would achieve, because that comparison tells you what labeling effort would buy. When to stop being zero-shot Zero-shot learning is a starting point, not a destination. For most applied problems, a small number of labeled examples improves performance substantially, and the methods for using them have become very efficient. The question is when the switch is worth making. The evidence of the previous chapters suggests a rule of thumb. If your categories and images are well covered by the model's training data, zero-shot performance may already be close to what few-shot adaptation achieves, and adaptation may even reduce robustness to shifts you have not anticipated, as the fine-tuning dilemma of the eighth chapter showed. If coverage is poor, a few labeled examples carry information the model simply does not have, and they will help far more than any amount of prompt engineering. Several adaptation methods preserve the benefits of the zero-shot starting point. Linear probing trains only a classifier on the frozen image features; it is cheap and robust but cannot correct a representation that fails to separate your classes. Prompt learning methods such as CoOp and CoCoOp, described in the seventh chapter, learn a small number of parameters on the text side; evaluate them on held-out classes to check they have not overfit to the training classes. Adapters insert small trainable modules into frozen networks. Weight-space ensembling in the style of WiSE-FT interpolates between the zero-shot and fine-tuned models to retain robustness. Initializing a classifier from text embeddings, using each class's ensembled text embedding as the starting weight vector of a linear classifier, combines zero-shot knowledge with few-shot evidence and often outperforms either alone in low-data regimes. There is also the domain-model option. If your field has a vision-language model trained on domain-specific paired data, such as the pathology and biomedical models discussed in the eighth chapter, it will usually beat a general model zero-shot within that domain, because its training data spans the domain. Where no such model exists and the application justifies the investment, curating domain image-text pairs, perhaps from existing reports, catalogs or annotated archives, and fine-tuning a general model contrastively on them is a direct way to extend the bridge. A worked scenario Consider a conservation team with a network of camera traps in a tropical forest. They want to sort hundreds of thousands of images by species, including some species for which they have no labeled images. How should they proceed? The coverage check is mixed. Common large mammals are well represented on the web; rare small mammals, many birds and some regional species are not. Camera-trap images differ from web photographs: many are taken at night in infrared, animals are often partially visible, blurred or at the edge of the frame, and many frames contain no animal at all. The distinctions between some species, such as similar small rodents, depend on features barely visible at camera-trap resolution. A sensible plan follows the chapter's sequence. Start with a strong general vision-language model and templates adapted to the domain ("a camera-trap photo of a {species}," "an infrared night photo of a {species}"), with each species name accompanied by its common name, scientific name and parent group. Add catch-all classes for empty frames, people, vehicles and unidentifiable animals. Run the model over a large unlabeled sample and inspect the prediction histogram; if a few species dominate, apply a prior correction. Label a modest validation set, a few hundred images spread across species and conditions, and use it to choose templates, calibrate, and set an abstention threshold. Evaluate per species and separately for day and night images. Compare with a domain-specific camera-trap model if one exists, since several have been developed by the conservation technology community. For species where zero-shot accuracy is poor, collect a handful of labeled examples and use them to initialize or adapt a classifier, monitoring held-out species to ensure the adaptation has not damaged generalization. Route low-confidence images to human reviewers, whose labels become the next round of training data. Nothing in this plan is exotic. Every step addresses a failure identified in earlier chapters: the coverage gap, the semantic gap, hubness, the bias toward familiar classes, the absence of abstention, the evaluation leak and the shift between conditions. The value of understanding zero-shot learning as borrowed generalization is that it tells the team where to look for trouble before the trouble arrives. Conclusion: What Borrowed Generalization Implies The story of zero-shot learning is usually told as a story of progress: from hand-annotated attributes to learned embeddings, from embeddings to generators, from generators to foundation models that classify anything a user can name. The progress is real. A task that in 2009 meant recognizing ten animal species from eighty-five attributes now means classifying photographs into arbitrary categories described in ordinary language, with accuracy that rivals supervised training on many everyday tasks. But told only as progress, the story hides its most useful lesson, which is that the mechanism never changed. At every stage, a model recognized a new category by locating a description of it in a semantic space and mapping an input into that space with a function trained on other categories. At every stage, the model's competence on the new category was bounded by how well the semantic space encoded the category's distinguishing features and by how well the mapping, fitted elsewhere, carried new inputs to the right place. Seen this way, several things follow that could not be said at the outset. What follows The first is that "zero-shot" names an interface, not an absence of evidence. When a model classifies goldfinches without having been trained on a labeled goldfinch dataset, it is drawing on evidence about goldfinches, either directly from captioned images in its pretraining data or indirectly from attributes, descriptions and relations that connect goldfinches to things it has seen. The 2017 discovery that "unseen" benchmark classes had been seen by the feature extractor, and the 2024 finding that zero-shot accuracy rises log-linearly with a concept's frequency in pretraining data, are the same discovery at two scales. Claims that a model "understands" a new concept because it recognizes it zero-shot should be read with this in mind. The model has organized a great deal of evidence well enough to retrieve it through language. That is a remarkable capability, and it is a different one from inferring a genuinely novel category from first principles. The second is that the long tail is where the method is weakest and where it is most needed. The motivation for zero-shot learning was always the categories no one had labeled: rare species, new products, unusual findings. These are precisely the categories that appear least often in any training corpus, labeled or not. A method whose competence scales with data coverage is, by construction, least competent where coverage is thinnest. Scaling pretraining data improves the long tail, but slowly, since each fixed gain requires a multiplicative increase in frequency. There is no reason to expect that general-purpose models will ever cover every specialized domain well, and good reason to expect that domain-specific paired data will remain the main route to competence in fields such as medicine, ecology, materials science and industrial inspection. The third is that the old pathologies are permanent features, not solved problems. Hubness is a property of nearest-neighbor search in high dimensions. Projection shift is a consequence of fitting a mapping on some classes and applying it to others. The semantic gap exists whenever side information is produced by a process other than looking at the inputs. Seen-class bias arises whenever a model is adapted to some categories and asked to weigh them against others. Scale reduces the magnitudes of these effects for well-covered concepts. It does not abolish them, and they return in full at the edges of coverage, in compositional queries, in open-vocabulary detection of rare objects, and in any system that mixes fine-tuned and zero-shot categories. A practitioner who knows their names can recognize them in a prediction histogram or a confusion matrix and apply corrections that have existed for a decade. The fourth is that evaluation is part of the method. The field's most consequential corrections came not from new architectures but from new protocols: clean splits, per-class accuracy, the generalized setting, the harmonic mean, held-out validation classes and, more recently, base-to-novel splits for prompt learning and frequency-stratified benchmarks for foundation models. Each corrected an inflation that had made methods appear to generalize further than they did. Any team claiming zero-shot performance owes its audience an account of what the model had and had not seen, and an evaluation that would have exposed the failure if it were there. What remains unsettled Several questions remain genuinely open. It is not clear how far compositional generalization can be pushed by scale. Contrastive models trained on billions of captions still struggle to distinguish "a lightbulb surrounding some plants" from "some plants surrounding a lightbulb." Training with hard negatives helps, and generative and multimodal language models handle some compositional queries better than dual encoders do. Whether any of these approaches yields systematic composition, the ability to combine any known attribute with any known object reliably, rather than better coverage of common combinations, is an open empirical question with large practical stakes. It is not clear how to measure novelty at web scale. Frequency analyses of pretraining data are expensive, depend on how concepts are matched to captions, and cannot easily account for indirect evidence, such as a rare species' resemblance to a common relative. Better tools for answering "how much evidence did this model have about this concept?" would make zero-shot claims far more interpretable and would let practitioners predict where a model will fail before deploying it. It is not clear how much synthetic data can extend coverage. Text-to-image generators can produce images of rare concepts, but only as well as they know them, and pipelines in which generators and classifiers share training data risk circularity. Whether synthetic data can add genuinely new knowledge, as opposed to reorganizing knowledge already present, is unresolved. And it is not clear how to make zero-shot systems know what they do not know. Abstention, calibration and out-of-distribution detection remain weaker than classification itself. A system whose competence depends on data coverage should be able to report when it is outside that coverage. Building that capacity reliably is arguably more important for deployment than another point of benchmark accuracy. What to do differently For a reader who will build, buy or evaluate a zero-shot system, the argument of this booklet reduces to a change of question. The natural question is "can this model recognize new things?" The useful question is "where did this model get the evidence it would need to recognize my things, and how would I know if it did not?" Answering it means asking about coverage before writing prompts: whether the categories, the imaging conditions and the distinctions in question appear in the kind of data the model learned from. It means treating class descriptions as side information that sets a ceiling, and writing them to encode the differences that matter. It means inspecting what the model predicts on unlabeled data before trusting it, correcting for the biases high-dimensional geometry and uneven training predictably introduce, and giving the system a way to abstain. It means evaluating on classes and conditions chosen to expose failure, with decisions made on held-out data. And it means being ready to stop being zero-shot, because a handful of labeled examples often carries exactly the evidence the model was missing. The child who recognizes a zebra from a single sentence is drawing on years of seeing horses, stripes and animals, and on a language that connects them. Machines that do something similar are drawing on the same kind of resources, gathered differently and at a different scale. Their generalization is no less impressive for being borrowed. But knowing that it is borrowed, and from where, is what makes it possible to use it well. Glossary Attribute. A human-nameable property shared across categories, such as "striped" or "has hooves," used as side information to describe classes. Calibrated stacking. A correction for seen-class bias in generalized zero-shot learning that subtracts a constant from every seen class's score before choosing the highest-scoring class. Compatibility function. A learned function that scores how well an input matches a class description; classification picks the class with the highest score. The bilinear form, a learned matrix between image and class vectors, is the most common. Compositional zero-shot learning. Recognizing unseen combinations of known components, such as a state and an object ("sliced tomato") when each has been seen separately. Contrastive pretraining. Training paired encoders, for example for images and text, so that matching pairs score higher than mismatched pairs within a batch. CLIP and ALIGN are trained this way. Conventional zero-shot learning. The evaluation setting in which test inputs come only from unseen classes and the model chooses only among unseen classes. Effective robustness. The amount by which a model's accuracy under distribution shift exceeds what would be predicted from its in-distribution accuracy, based on the trend followed by comparable models. Generalized zero-shot learning. The evaluation setting in which test inputs may come from seen or unseen classes and the model chooses among all classes. Harmonic mean (of seen and unseen accuracy). The headline metric for generalized zero-shot learning: twice the product of seen and unseen accuracy divided by their sum. It is high only when both are high. Hubness. The tendency, in high-dimensional spaces, for a few points to appear among the nearest neighbors of a disproportionate number of other points, causing nearest-neighbor classifiers to over-predict a few classes. Inductive setting. A zero-shot setting in which the model sees no unseen-class inputs, labeled or unlabeled, before test time. Modality gap. The observation that in contrastive vision-language models, image embeddings and text embeddings occupy separate regions of the shared space. Open-vocabulary detection. Object detection in which categories are specified by arbitrary text at test time, including categories without box annotations in training. Projection domain shift. The displacement of unseen-class inputs when mapped into a semantic space by a function fitted only on seen classes. Prompt ensembling. Averaging the text embeddings of several phrasings of a class description to produce a more robust class representation. Semantic gap. The mismatch between how classes are related in the semantic space (for example, by textual co-occurrence) and how they are related visually. Side information. Information about a class not derived from its training inputs, such as attributes, word embeddings, text descriptions or knowledge-graph relations, that allows unseen classes to be described. Transductive setting. A zero-shot setting in which the model may use unlabeled test inputs, all at once, before making predictions. Further Reading Lampert, Nickisch and Harmeling, "Learning to Detect Unseen Object Classes by Between-Class Attribute Transfer" (CVPR 2009), and the extended journal version "Attribute-Based Classification for Zero-Shot Visual Object Categorization" (IEEE TPAMI, 2014). The founding attribute paper, introducing Animals with Attributes and the direct and indirect attribute prediction methods. Palatucci, Pomerleau, Hinton and Mitchell, "Zero-Shot Learning with Semantic Output Codes" (NeurIPS 2009). An early formal treatment of when mapping into a semantic space allows recognition of unseen classes, applied to decoding words from brain activity. Frome et al., "DeViSE: A Deep Visual-Semantic Embedding Model" (NeurIPS 2013). The paper that brought deep image features and word embeddings together for zero-shot recognition at ImageNet scale. Xian, Lampert, Schiele and Akata, "Zero-Shot Learning — A Comprehensive Evaluation of the Good, the Bad and the Ugly" (IEEE TPAMI, 2018). The essential reassessment of the classic benchmarks, introducing clean splits and the harmonic-mean protocol for the generalized setting. The best single entry point to the pre-CLIP literature. Chao, Changpinyo, Gong and Sha, "An Empirical Study and Analysis of Generalized Zero-Shot Learning for Object Recognition in the Wild" (ECCV 2016). The clearest demonstration of seen-class bias and the source of calibrated stacking. Radovanović, Nanopoulos and Ivanović, "Hubs in Space: Popular Nearest Neighbors in High-Dimensional Data" (JMLR, 2010), and Shigeto et al., "Ridge Regression, Hubness, and Zero-Shot Learning" (ECML PKDD 2015). Together, the explanation of hubness and why reversing the direction of the mapping reduces it. Xian, Lorenz, Schiele and Akata, "Feature Generating Networks for Zero-Shot Learning" (CVPR 2018). The paper that established feature generation as the dominant approach to generalized zero-shot learning on the classic benchmarks. Radford et al., "Learning Transferable Visual Models From Natural Language Supervision" (ICML 2021). The CLIP paper. Long, candid about failures and data overlap, and still the best account of how prompt engineering and ensembling work in practice. Zhou, Yang, Loy and Liu, "Learning to Prompt for Vision-Language Models" (IJCV 2022) and "Conditional Prompt Learning for Vision-Language Models" (CVPR 2022). CoOp and CoCoOp, and the base-to-novel evaluation that revived the generalized protocol for foundation models. Wortsman et al., "Robust Fine-Tuning of Zero-Shot Models" (CVPR 2022). WiSE-FT and a clear treatment of the trade-off between fine-tuning gains and zero-shot robustness. Fang et al., "Data Determines Distributional Robustness in Contrastive Language Image Pre-training (CLIP)" (ICML 2022), and Udandarao et al., "No 'Zero-Shot' Without Exponential Data: Pretraining Concept Frequency Determines Multimodal Model Performance" (NeurIPS 2024). The two most direct pieces of evidence that vision-language zero-shot generalization is borrowed from pretraining data. Menon and Vondrick, "Visual Classification via Description from Large Language Models" (ICLR 2023), with Roth et al., "Waffling Around for Performance: Visual Classification with Random Words and Broad Concepts" (ICCV 2023). Read together: the first shows how language-model descriptions revive the attribute idea; the second shows why every claimed gain from side information needs a control. Hashtags: #ZeroShotLearning #ZSL #GeneralizedZeroShotLearning #GZSL #SemanticEmbeddings #CrossDomainGeneralization #ArtificialIntelligence #MachineLearning #DeepLearning #TransferLearning #SemanticLearning #VisualSemanticEmbeddings #CrossModalLearning #VisionLanguageModels #CLIP #ContrastiveLearning #ZeroShotClassification #ZeroShotRecognition #ZeroShotTransfer #OpenVocabularyLearning #OpenWorldRecognition #SemanticAttributes #AttributeBasedLearning #KnowledgeGraphs #WordEmbeddings #TextEmbeddings #ImageEmbeddings #MultimodalAI #FoundationModels #RepresentationLearning #DomainAdaptation #DomainGeneralization #DistributionShift #SemanticGap #ProjectionDomainShift #HubnessProblem #SeenClassBias #UnseenClassRecognition #CompositionalGeneralization #PromptEngineering #PromptLearning #NaturalLanguageDescriptions #GenerativeModels #ConditionalGAN #VariationalAutoencoders #SyntheticFeatureGeneration #FewShotLearning #OpenSetRecognition #OutOfDistributionDetection #ModelCalibration #HarmonicMeanAccuracy #SemanticSimilarity #CrossModalRetrieval #VisualRecognition #ComputerVision #AIResearch

Download the Book (PDF): Introduction Stand at the end of an aisle in a busy distribution centre at two in the morning and watch what a mobile robot has to cope with. The racking runs in straight, regular lines, which seems helpful until you notice that every aisle looks almost exactly like every other aisle. A pallet that was at the end of row fourteen an hour ago has been moved to a staging lane. A pallet jack has been abandoned at an angle across half the walkway. A picker in a high-visibility vest steps out from between two bays without looking. Shrink-wrap on a load catches the overhead lighting and throws it back as a hard specular glare. A forklift reverses with its forks raised, so the only part of it at the robot's sensor height is two thin steel tines. Somewhere a dock door opens and a wedge of daylight floods across the polished concrete. None of this troubles a human worker. We do not think of ourselves as solving a perception problem when we walk down that aisle. But a robot that must move through the same space, safely and productively, for twenty hours a day, has to do explicitly what we do without effort: measure the geometry of its surroundings, recognise the things in it that matter, work out where it is, maintain some model of the space it can plan against, and keep all of these consistent while the world shifts around it. Each of those tasks has its own body of technique. Depth cameras measure geometry. Object detectors recognise things. Localization estimates position. Mapping builds a model of the space. Simultaneous localization and mapping, universally abbreviated SLAM, does the last two at once, because neither can be done well without the other. This booklet is about how those pieces work and, more importantly, how they fit together in the setting that tests them hardest: the dynamic, semi-structured warehouse, where the building is fixed but almost everything inside it moves. The argument The central claim of this book is simple to state and takes the rest of the book to earn. A robot does not see the world; it estimates it. Every measurement a robot takes is noisy, partial and occasionally wrong. Every model it builds is a hypothesis held with some degree of confidence. The systems that work in real warehouses are the ones designed from the start to reason about that uncertainty explicitly, to keep track of how much they trust each piece of what they believe, and, critically, to distinguish between the parts of the world that are permanent and the parts that are passing through. That last distinction is where the two halves of the title meet. Classical SLAM was developed largely under the assumption that the world is static: the robot moves, the scenery does not. Object detection was developed largely as a problem of labelling single images, with no notion of a map or of time. Neither assumption holds in a warehouse. A SLAM system that treats a parked forklift as a wall will build a map that is wrong by the next shift. A detector that labels a person in one frame but has no idea where that person was half a second ago cannot help a planner predict where they will be half a second from now. The practical frontier in warehouse robotics is the fusion of the two: geometry that knows what things are, and recognition that knows where things are and how long they are likely to stay there. Put differently, the hard part is not building a map. Robots have been building good maps of static rooms for decades. The hard part is building a map you can trust tomorrow, in a building where a meaningful fraction of what the sensors see today will be somewhere else by then. What this book covers, and what it leaves out The chapters follow the flow of information through a robot's perception system, from photons to motion commands. The first chapter sets out the probabilistic way of thinking that the rest of the book depends on: why perception is best treated as estimation, what a belief is, and how Bayes' rule turns noisy measurements into useful knowledge. It is the one chapter that is mostly about ideas rather than hardware, and it pays for itself many times over in the chapters that follow. The second chapter turns to depth cameras, the sensor that has done more than any other to make visual perception practical on low-cost mobile robots. It explains how structured light, time-of-flight and active stereo cameras actually produce a depth value for each pixel, how their errors behave, and why warehouses in particular are full of surfaces that defeat them. The third chapter covers object detection: how modern neural networks find and label pallets, people and vehicles in images, how they are evaluated, how two-dimensional detections are lifted into three-dimensional positions using depth, and what it takes to run them fast enough on the computer a robot can carry. The fourth and fifth chapters take on localization and SLAM. Localization is the narrower problem of knowing where you are on a map you already have; SLAM is the harder problem of building that map while relying on it. These chapters explain odometry and its drift, Kalman and particle filters, feature-based and direct visual SLAM, and the pose-graph optimisation and loop closure that hold large maps together. The sixth chapter is devoted to occupancy grid maps, the humble but indispensable representation that most mobile robots actually plan against. It shows how a depth image becomes evidence about which cells of space are free and which are occupied, and why the log-odds formulation that underpins it is one of the quiet triumphs of robotics. The seventh chapter confronts the dynamic world directly: how moving and moved objects corrupt both localization and maps, and the strategies, from robust statistics to semantic masking to layered and decaying maps, that keep a robot's model of a warehouse honest over weeks and months. The eighth chapter follows the map into motion, through global and local planning, costmaps, human-aware navigation and the safety standards that govern autonomous mobile robots in industrial spaces. The ninth and final chapter is about the gap between a robot that works in a demonstration and a fleet that works on a Tuesday in December: evaluation metrics, simulation, field testing, map management across many robots, and the long tail of failures that only appear at scale. Some things are deliberately left out. Lidar receives attention throughout, because most production warehouse robots carry at least one planar lidar for safety and localization and it would be dishonest to pretend otherwise, but this is not a lidar book and it does not cover lidar hardware in depth. Manipulation, the problem of picking items from shelves or bins, is a large field of its own and is touched on only where it shares perception machinery with navigation. Outdoor robotics, autonomous driving and aerial vehicles share many of the same algorithms but face different sensors and different constraints, and they appear only as occasional points of comparison. And the book does not attempt to survey every published SLAM system or detector architecture; there are hundreds, and the field moves monthly. The aim instead is to explain the principles well enough that a reader can understand any new system on its own terms and judge whether it is likely to survive contact with a real building. Who this is for The book is written for intelligent readers who are not yet specialists: engineers moving into robotics from software or mechanical backgrounds, operations and automation leaders who need to evaluate what vendors are telling them, students who want a coherent picture before diving into the research literature, and technically curious readers who have watched warehouse robots on video and wondered how they avoid running into things. It assumes comfort with basic algebra and a willingness to follow an argument about probability, and nothing more. Where mathematics clarifies an idea it is described in words first; where a short snippet of code makes a mechanism concrete, it is kept to a few lines. A reader who finishes it should be able to look at a warehouse robot and say, with some precision, what it is probably sensing, how it is probably building and using its map, where it is most likely to fail, and what questions to ask of anyone who claims it will not. Chapter 1: Perception as Estimation A robot's sensors never report the world directly. A depth camera reports a number for each pixel that is supposed to be the distance to the nearest surface along that pixel's line of sight, but the number is perturbed by noise, quantised by the electronics, biased by the surface's colour and angle, and sometimes simply missing. A wheel encoder reports how many ticks the motor shaft has turned, which is related to how far the robot has travelled only if the wheel did not slip, the tyre did not compress, and the floor was flat. A camera image reports brightness values that depend on the scene, but equally on the lighting, the exposure setting, the lens and the motion blur of the moment it was captured. The mistake that newcomers to robotics most often make, and that early robotic systems made too, is to treat these readings as facts. If the depth camera says there is a surface at 2.31 metres, the robot believes there is a surface at 2.31 metres, marks it in its map, and moves on. This works in a laboratory for a while. It fails in a warehouse almost immediately, because the errors accumulate, contradict each other and, with nothing to reconcile them, produce a model of the world that is confidently wrong. The alternative, which has dominated robotics since the 1990s and is the foundation of everything in this book, is to treat perception as estimation. The robot does not know the state of the world. It holds a belief about that state: a probability distribution over the possibilities, which it updates as evidence arrives. Measurements do not overwrite the belief; they shift it, by an amount that depends on how reliable the measurement is and how surprising it is given what the robot already thought. Beliefs, states and evidence The word state in robotics means whatever quantities the robot needs to know in order to act. For a mobile robot navigating a warehouse floor, the most basic state is its pose: its position on the floor, usually two coordinates, and its heading, one angle. Three numbers. A robot that knew its pose exactly, and had an exact map of everything it might hit, could plan perfectly. It never knows either exactly. So instead of a single pose, the robot maintains a distribution over poses. In the simplest useful case this distribution is a Gaussian, the familiar bell curve generalised to several dimensions: a best guess for the pose, together with a covariance that describes how uncertain that guess is and in which directions. A robot that has just driven a long way down a featureless aisle might be fairly sure of its lateral position, because the racks on either side constrain it, but quite unsure of how far along the aisle it has come, because nothing it can see distinguishes one bay from the next. Its uncertainty would be an elongated ellipse, long along the aisle, narrow across it. That shape is information. It tells the robot which kinds of evidence would help most, and it tells a planner which manoeuvres are risky. The map, too, is part of the state. In an occupancy grid, which Chapter 6 covers in detail, the floor is divided into small cells and the robot maintains, for each cell, a probability that it is occupied. A cell the robot has never observed sits at fifty per cent: no evidence either way. A cell it has seen as empty many times drifts towards zero. A cell that consistently returns depth readings drifts towards one. The map is not a picture of the warehouse. It is a large collection of beliefs about the warehouse, each with its own degree of confidence. Objects are part of the state as well, when the robot cares about them. A detected person is not just a bounding box in one image; it is a belief about a position and velocity on the floor, with its own uncertainty, which can be predicted forward in time and corrected by the next detection. Bayes' rule as the engine The machinery that updates beliefs is Bayes' rule, and it is worth understanding in words because every algorithm in this book is, at bottom, a way of applying it efficiently. Bayes' rule says that your belief in a hypothesis after seeing some evidence is proportional to two things multiplied together: how plausible the hypothesis was before the evidence, and how likely that evidence would have been if the hypothesis were true. The first factor is the prior. The second is the likelihood, and in robotics it is supplied by a sensor model: a description of what readings the sensor tends to produce when the world is in a given state. Consider a single cell in an occupancy grid, and a depth camera that has just reported a surface exactly at that cell's location. If the camera were perfect, this would settle the matter. But suppose experience shows that when a cell is truly occupied, the camera reports a hit there about seventy per cent of the time (sometimes it misses dark or angled surfaces), and when a cell is truly empty, it reports a spurious hit there perhaps five per cent of the time (noise, reflections, a passing person). A single hit, then, is evidence for occupancy roughly fourteen times stronger than evidence against. Starting from even odds, one hit makes occupancy much more likely but not certain. Three hits in a row make it very likely. A hit followed by four clear views through the cell pulls it back down. The rule handles all of this without special cases: each observation multiplies the odds by its likelihood ratio, and the belief settles where the evidence, weighed by its reliability, points. That multiplicative structure is the reason robotics so often works with log-odds rather than probabilities. Taking logarithms turns the multiplications into additions. Each new observation simply adds a fixed positive amount to a cell's score if it was seen as occupied and subtracts a fixed amount if it was seen as free. The arithmetic is trivial, fast, and numerically stable. The occupancy grid algorithm that Hans Moravec and Alberto Elfes introduced in the mid-1980s, and that Elfes set out in his 1989 article in IEEE Computer, is essentially this observation applied to millions of cells at once. The same logic, in more elaborate form, underpins localization. The robot's belief about its pose is the prior; the sensor model says how likely the current depth scan would be from each candidate pose, given the map; Bayes' rule combines them. Everything else is detail about how to represent the distribution and compute the update fast enough to matter. Prediction and correction A robot's belief changes for two reasons, and it helps to keep them separate. It changes because the robot moves, and it changes because the robot senses. When the robot moves, its belief about its pose should become less certain. It commanded the wheels to drive a metre forward, the encoders report something close to a metre, but slip, uneven floors and calibration errors mean the true displacement is somewhere in a small cloud around that figure. So the belief is shifted by the commanded or measured motion and simultaneously spread out by the motion noise. This is the prediction step, governed by a motion model. When the robot senses, its belief should become more certain, provided the sensing is informative. The new measurement is compared with what the robot expected to see from each candidate state, and states that explain the measurement well gain probability while those that explain it poorly lose it. This is the correction or update step, governed by the sensor model. Alternating prediction and correction is the structure of a Bayes filter, and almost every practical estimator in robotics is a Bayes filter in some form. The Kalman filter, which Chapter 4 describes, is the exact Bayes filter for the special case where beliefs are Gaussian and the models are linear. The particle filter represents the belief as a cloud of weighted samples and handles almost any shape of distribution at the cost of more computation. The factor-graph optimisers used in modern SLAM, covered in Chapter 5, are a way of solving the same problem over the whole trajectory at once rather than step by step. The rhythm of prediction and correction also gives a useful diagnostic vocabulary. A robot that becomes lost has usually suffered one of two failures. Either its prediction was worse than it believed, because its wheels slipped more than its motion model allowed for, or its correction was wrong, because a sensor reading was matched to the wrong part of the map. The first failure produces gradual drift. The second produces sudden jumps. Both are common in warehouses, and they need different remedies. Why uncertainty must be honest The most important practical lesson of the probabilistic view is that an estimator is only as good as its account of its own uncertainty. A robot that is unsure but knows it is unsure can slow down, look around, or ask for help. A robot that is unsure but believes it is certain will drive confidently into a rack. This matters because the errors in robot perception are rarely the polite, independent, bell-shaped noise that textbook derivations assume. Real errors are correlated: a miscalibrated camera mount produces the same bias in every frame, so a thousand frames do not average it away. Real errors are heavy-tailed: most depth readings are within a few millimetres, but occasionally a reflection produces a reading that is metres off. Real errors depend on context: a depth camera's noise grows with distance, roughly with its square for stereo systems, and with the surface's reflectivity and angle. A filter that treats every reading as independent and Gaussian with a fixed variance will become overconfident, because it counts correlated evidence many times over, and it will be thrown badly off by outliers, because a Gaussian assigns such outliers almost no probability and so must contort the whole estimate to explain them. Practitioners use several defences, which recur throughout this book. They inflate noise parameters beyond what laboratory tests suggest, deliberately trading a little precision for a lot of robustness. They use robust sensor models with heavier tails, so that a wild reading is treated as probably an outlier rather than as strong evidence. They gate measurements, refusing to incorporate any reading that is wildly inconsistent with the current belief. And they subsample: rather than feeding every one of the hundreds of thousands of depth pixels in each frame into the map, they take a sparse, spatially distributed subset, which reduces the effect of correlated errors and saves computation besides. None of these is a hack layered on top of the theory. Each is a way of making the sensor and motion models closer to the truth about how the hardware behaves. The probabilistic view does not ask that measurements be perfect. It asks only that their imperfections be described honestly. Frames, transforms and the geometry of belief One more piece of groundwork makes everything that follows easier. A robot's perception system involves many coordinate frames, and a large fraction of real-world bugs come from confusing them. There is the map frame, fixed to the building, in which the occupancy grid and the robot's global pose are expressed. There is the odometry frame, in which the robot's wheel-based motion estimate is expressed; it is continuous and smooth but drifts away from the map frame over time. There is the robot's base frame, attached to its chassis, usually centred between the drive wheels on the floor. And there is a frame for every sensor: the depth camera's optical frame, the lidar's frame, the inertial measurement unit's frame, each offset and rotated relative to the base by the way it was mounted. Turning a depth pixel into a mark on the map means chaining transforms: from pixel coordinates to a three-dimensional point in the camera's optical frame using the camera's intrinsic calibration, from the camera frame to the base frame using the extrinsic calibration of the mount, and from the base frame to the map frame using the current pose estimate. Every link in that chain is uncertain. An extrinsic error of one degree in the camera's pitch, which is easy to introduce by bumping the mount during maintenance, displaces a point five metres away by nearly nine centimetres vertically, enough to make the floor appear to slope or to make a low obstacle vanish into the ground plane. The probabilistic view says that this uncertainty belongs in the estimate too, and the most careful systems do estimate extrinsics online. Most systems simply calibrate carefully and check often, which is a reasonable choice provided someone actually does it. In the Robot Operating System, ROS 2, which the majority of research and a large share of commercial warehouse robots use in some form, these relationships are managed by a library called tf2 that maintains a time-stamped tree of transforms and answers queries such as "where was the camera relative to the map at the instant this image was captured?" The time stamp in that query is not a nicety. A robot turning at one radian per second rotates by nearly three degrees in fifty milliseconds, which is a typical latency between a camera capturing a frame and the software receiving it. Using the pose from the wrong instant smears every obstacle sideways. Synchronising clocks and stamping data at capture rather than at receipt is unglamorous engineering, but much of what is called perception failure in the field turns out to be timing failure in disguise. The shape of the problem in a warehouse With this vocabulary in place, the particular difficulty of the warehouse can be stated precisely. The state the robot must estimate is large: its own pose, the occupancy of every cell on a floor that may cover tens of thousands of square metres, and the positions and motions of the people, vehicles and loads that matter for safety and for the task. The evidence comes from sensors that are cheap enough to fit on a robot sold in fleets of hundreds, and therefore noisy. The motion model is degraded by floors that are polished, dusty, wet near the dock doors, or scored by years of forklift traffic. Above all, the world violates the assumption most classical algorithms rely on, that what the robot observes is static. A Bayes filter for a static map treats each observation of a cell as independent evidence about a fixed truth. If a pallet sits in a lane for an hour, the robot accumulates strong evidence that the lane is blocked. When the pallet is removed, the filter must accumulate an equal weight of contrary evidence before it believes the lane is clear, and in the meantime it will plan around a ghost. Worse, if the robot uses those pallet observations to localise itself, it will be matching its scans against a feature that no longer exists, and its pose estimate will slip. Everything in the chapters that follow can be read as a response to this tension between the need to accumulate evidence, which requires assuming some things stay put, and the reality of a building in which many things do not. The sensors determine how good the raw evidence is. Detection determines whether the robot can tell a wall from a pallet from a person. SLAM and localization determine how the evidence is fused into a consistent pose and map. And the treatment of dynamics determines whether that map is still true tomorrow. Chapter 2: How Depth Cameras Measure the World An ordinary camera throws away the single most important quantity a mobile robot needs. Each pixel records how much light arrived from some direction, but not how far that light travelled. A small box close to the lens and a large box far away can produce identical images. Humans recover depth from a dozen cues, among them binocular disparity, motion parallax, familiar size, texture gradients, shading and occlusion, and we do it so fluently that the loss is invisible to us. A robot that must not hit things cannot afford to infer distance from cues that sometimes mislead. It needs to measure it. For most of the history of mobile robotics, that measurement came from scanning rangefinders: first sonar rings, then laser scanners that swept a single beam across a horizontal plane and reported a distance for each angle. Planar lidar remains the backbone of warehouse robot safety and localization, and with reason. It is accurate to a centimetre or two, works in the dark, and has a well-understood error model. But it sees only one slice of the world, typically at a height of fifteen to thirty centimetres. A forklift's raised tines, a pallet overhanging the edge of a rack, a cable strung across an aisle, a box lying flat on the floor below the scan plane: all of these are invisible to a planar scanner. The depth camera fills that gap. It produces an image in which every pixel carries a distance, at video rates, over a field of view comparable to an ordinary camera, from a device that costs a few hundred dollars and draws a few watts. The arrival of the original Microsoft Kinect in 2010, built on structured-light technology from the Israeli company PrimeSense and sold as a games accessory at a consumer price, transformed robotics research almost overnight; within a year, laboratories everywhere had bolted Kinects to their robots and were publishing dense three-dimensional reconstruction and RGB-D SLAM results that would have required far more expensive hardware a few years earlier. The technology has since matured and diversified. Three distinct physical principles dominate, and they fail in different ways. Structured light A structured-light camera projects a known pattern of infrared light into the scene, typically a pseudo-random field of dots, and observes it with an infrared camera mounted a short distance away from the projector. When the pattern falls on a nearby surface, each dot appears displaced in the camera image relative to where it would fall on a distant surface; the displacement is inversely proportional to the distance. By recognising which local patch of the known pattern it is looking at and measuring how far that patch has shifted, the camera computes depth by triangulation. The original Kinect worked this way, as did many of its successors in the Orbbec Astra range and the early Intel RealSense SR300 short-range cameras. Structured light is accurate at short range, produces dense depth on textureless surfaces because it supplies its own texture, and needs relatively modest processing. Its weaknesses follow directly from its physics. Because it relies on the camera seeing its own projected pattern, anything that drowns the pattern destroys the measurement. Direct sunlight contains a great deal of infrared energy at the wavelengths these projectors use and washes the dots out entirely, which is why structured-light cameras are largely confined to indoor use and why a robot crossing a sunlit patch near an open dock door can briefly lose most of its depth image. Two structured-light cameras pointing at the same surface interfere with each other's patterns. And because the measurement is a triangulation across a short baseline, the error grows rapidly with distance. Time of flight A time-of-flight camera measures distance by timing light. In principle this could be done directly, by firing a short pulse and timing its return at each pixel, and some sensors do exactly that; but the most common consumer and industrial designs use a continuous-wave approach. The camera floods the scene with infrared light whose intensity is modulated at a high frequency, tens of megahertz, and each pixel measures the phase shift between the emitted and returned modulation. Since the light travels to the surface and back, the phase shift is proportional to twice the distance. The second-generation Kinect for Xbox One, the Microsoft Azure Kinect developer kit and its licensed successors from Orbbec, the Femto series, and a number of industrial cameras from companies such as ifm, Basler and Lucid work on this principle. Time-of-flight cameras produce depth that is relatively uniform in accuracy across their range, because the error does not grow with the square of distance as triangulation error does. They need no baseline, so the sensor can be compact. They work on textureless surfaces. But they have their own characteristic failures, and warehouse environments are rich in the conditions that trigger them. The first is phase wrapping. A phase measurement repeats every full cycle of the modulation, so a surface at one distance and a surface exactly one ambiguity interval further away produce the same reading. At a modulation of 20 megahertz the interval is 7.5 metres. A highly reflective surface far down an aisle can therefore appear to be much closer than it is. Cameras mitigate this by combining measurements at several modulation frequencies, which extends the unambiguous range at the cost of more complex processing and more opportunities for artefacts. The second is multipath interference. The phase measurement assumes that the light arriving at a pixel travelled directly from the emitter to one surface and back. In a corner, or near a shiny floor, some light bounces off one surface onto another before returning, arriving later and corrupting the phase. The result is depth that bulges or sags near concave corners and floors, which is exactly where a robot needs it to be right. The third is flying pixels. At the edge of an object, a single pixel may receive light from both the near object and the far background. The phase it reports is a blend of the two and corresponds to a distance somewhere in between, at which there is no surface at all. A depth image of a pallet in front of a distant wall is fringed with points floating in empty space, which an unwary mapping system will dutifully insert into its map as small obstacles. Active stereo A stereo camera mimics human binocular vision: two cameras a known distance apart, the baseline, capture the scene simultaneously, and for each point in one image the system searches along the corresponding row of the other image for the matching point. The horizontal offset between the two, the disparity, is inversely proportional to depth. Purely passive stereo, using ordinary visible-light cameras, works well outdoors and on richly textured scenes, and systems such as the Stereolabs ZED cameras use it successfully, increasingly with neural networks doing the matching. But it fails on surfaces with no texture to match: a plain painted wall, a white cardboard box, a smooth concrete floor. A warehouse is full of such surfaces. Active stereo solves this by adding an infrared projector that sprays a random dot pattern onto the scene, supplying texture where there is none, while retaining the ability to use natural texture where it exists. The Intel RealSense D400 series, introduced in 2018 and by a wide margin the most common depth cameras on research and commercial mobile robots since, works this way; in 2025 the RealSense business was spun out of Intel as an independent company, and the D400 line has continued. Because active stereo can still match ambient texture, it degrades more gracefully in sunlight than pure structured light: when the projected dots wash out, the cameras can still match whatever natural texture the bright scene offers. The governing equation of stereo is worth stating in words, because it explains the sensor's behaviour better than any datasheet. Depth equals focal length times baseline divided by disparity. Since disparity can be measured only to some fraction of a pixel, the depth error grows with the square of distance and shrinks with longer baselines and longer focal lengths. Doubling the distance to a surface quadruples the uncertainty of its depth. A camera with a 50-millimetre baseline that is accurate to a few millimetres at half a metre may be uncertain by several centimetres at four metres and by tens of centimetres at ten. This is not a defect of a particular product; it is geometry. It has a direct consequence for mapping: depth readings from far away should carry much less weight than readings from close by, and a mapping system that ignores this will blur its distant walls into thick, uncertain bands. Comparing the three principles The three technologies trade off in ways that matter when choosing a sensor for a particular robot, as Table 1 sets out. None dominates; the right choice depends on the range the robot needs to see, the lighting it will encounter, and the surfaces it must handle. Table 1. Principal depth-sensing technologies used on indoor mobile robots. Principle How depth is obtained Error behaviour with range Typical strengths Typical failure modes Structured light Triangulates a projected IR pattern Grows rapidly (roughly with square of range) Dense on textureless surfaces; modest compute Sunlight washout; interference between units; short useful range Continuous-wave time of flight Phase shift of modulated IR light Roughly uniform across range Compact; no baseline; good mid-range accuracy Phase wrapping; multipath in corners and on shiny floors; flying pixels at edges Active stereo Matches two views, aided by projected dots Grows with square of range; shrinks with longer baseline Degrades gracefully outdoors; uses natural texture Mismatches on repetitive patterns; holes on dark or reflective surfaces Warehouse surfaces that defeat depth Every depth camera relies on light returning from the surface it is measuring, and a warehouse contains an unusual concentration of surfaces that return light badly or misleadingly. Black stretch wrap and dark plastic totes absorb much of the infrared energy that reaches them, returning too little for a reliable measurement. The camera reports no depth, leaving holes in the image. A hole is not an obstacle-free region; it is an absence of evidence, and a mapping system must treat it as such rather than as empty space. Clear stretch wrap and shrink-wrap are worse, because they are partly transparent and partly specular. Some of the light passes through and returns from the boxes behind; some reflects off the film in a mirror-like way and either misses the camera entirely or produces a bright, misleading return. The resulting depth can be noisy, biased or wildly wrong from frame to frame as the robot's angle changes. Polished concrete floors, especially when freshly cleaned, act as partial mirrors at shallow angles. A time-of-flight camera looking down an aisle may see reflections of the racking in the floor and report them as surfaces below ground level, or suffer multipath errors that make the floor appear to curve. Repetitive structures such as rack uprights punched with identical holes at regular intervals, wire mesh decking, and safety netting can fool stereo matching. The algorithm finds a plausible match one repetition away from the true one and reports a confident but wrong depth. Thin structures such as forklift tines seen edge on, the rails of a pallet jack, hanging cables, and the legs of a step ladder may fall between the dots of a projected pattern or be too thin to match reliably, so they appear patchily or not at all. None of these failures is exotic. A robot spending a shift in a busy warehouse will encounter all of them, many times. The practical consequence is that raw depth must be filtered before it is trusted, and that a robot should never rely on depth alone for safety-critical detection of the obstacles it most needs to see. Calibration, filtering and placement Three engineering practices determine whether a depth camera's output is usable. The first is calibration. A depth camera has intrinsic parameters, describing its focal length, optical centre and lens distortion, and, for stereo and structured-light units, the precise geometry between its internal cameras and projector. Manufacturers calibrate these at the factory, but they can drift with temperature, shock and age, and a stereo camera with even a slight error in its internal alignment will produce depth that is systematically warped. Most modern units provide an on-board self-calibration routine, and it is worth running it routinely. The extrinsic calibration, the camera's position and orientation on the robot, is the integrator's responsibility; the standard approach is to have the robot view a known target, such as a checkerboard or a flat floor of known height, and solve for the transform that makes the observations consistent. The second is filtering. Common steps include discarding readings beyond a trusted maximum range, rejecting pixels whose neighbours disagree sharply with them (which removes most flying pixels), applying a temporal filter that requires a reading to persist over a few frames before it is trusted, and downsampling to a voxel grid so that a dense patch of returns from one surface does not count as thousands of independent observations. Each filter trades responsiveness for reliability, and the right setting depends on how fast the robot moves and how quickly obstacles can appear. The third is placement. A camera mounted high and pitched down sees the floor in front of the robot well and can detect low obstacles, but has a large blind zone immediately ahead of the bumper. A camera mounted low and level sees far down the aisle but sees the floor poorly and is easily blocked by dirt and splashes. Many warehouse robots carry two or more depth cameras for this reason, one angled down to watch the floor directly ahead and one looking forward and upward to catch overhanging loads and raised forks. Their fields of view must be arranged so that every obstacle that could enter the robot's path is seen by at least one sensor before the robot reaches it, at the robot's maximum speed and given its stopping distance. That calculation, rather than any property of the camera, is often what determines a robot's maximum safe velocity. A depth camera, then, is not a device that reports the geometry of the world. It is a device that reports a noisy, structured, sometimes systematically biased estimate of that geometry, with failure modes that can be anticipated from its physics. Treating its output in that spirit is the first step towards a perception system that works. Chapter 3: Object Detection, From Pixels to Things Geometry tells a robot that something is there. It does not tell the robot what that something is, and in a warehouse the difference between things is often the difference between right and wrong behaviour. A cardboard box in the aisle is an obstacle to be avoided and perhaps reported. A person is an obstacle that moves unpredictably, must be given a wide berth, and whose presence may require the robot to slow down by regulation. A forklift is a fast, heavy vehicle with a large blind spot, whose path the robot should never cross closely. A pallet in a pick location may be the robot's goal rather than an obstacle at all. A depth camera sees all four as clusters of points of roughly similar size. Object detection is what turns those clusters into things. What a detector does An object detector takes an image and returns a list of objects, each described by a class label such as person, pallet or forklift, a location, usually an axis-aligned bounding box in the image, and a confidence score between zero and one. Closely related tasks return more detailed shape information: instance segmentation labels every pixel belonging to each object, and keypoint detection locates specific parts, such as a person's joints or the corners of a pallet's fork pockets. The modern history of detection begins in 2012, when a deep convolutional neural network, later known as AlexNet, won the ImageNet image-classification competition by a margin that ended the debate about whether learned features would replace hand-designed ones. Detection followed quickly. Ross Girshick and colleagues' R-CNN, published in 2014, proposed candidate regions with a classical algorithm and classified each with a convolutional network. It was accurate but slow, taking many seconds per image. Successive refinements culminated in Faster R-CNN in 2015, by Shaoqing Ren, Kaiming He, Girshick and Jian Sun, which replaced the external region proposer with a small network that shared computation with the classifier, bringing detection to several frames per second on a desktop graphics card. These are two-stage detectors: first propose regions that might contain an object, then classify and refine each one. In 2016, Joseph Redmon and colleagues introduced YOLO, for "You Only Look Once," which abandoned the proposal stage and predicted boxes and classes for a coarse grid of image cells in a single pass. The original YOLO was less accurate than Faster R-CNN, especially on small objects, but it ran in real time, and its descendants have closed most of the accuracy gap. The single-shot detector, SSD, published the same year by Wei Liu and colleagues, took a similar approach. RetinaNet, from Tsung-Yi Lin and colleagues in 2017, identified one reason single-stage detectors lagged, namely that the overwhelming majority of candidate locations are easy background, and introduced the focal loss, which down-weights easy examples so the network concentrates on the hard ones. In 2020, Nicolas Carion and colleagues at Facebook AI Research published DETR, which reframed detection as a set-prediction problem solved with a transformer. Rather than producing thousands of candidate boxes and then pruning duplicates with a hand-tuned step called non-maximum suppression, DETR predicts a fixed-size set of objects directly and is trained to match them one-to-one with the ground truth. Early versions trained slowly and struggled with small objects; later variants such as Deformable DETR and RT-DETR, a real-time variant published by researchers at Baidu in 2023, addressed both. Today, real-time detectors in both the YOLO lineage and the DETR lineage are widely deployed, and the choice between them is driven more by tooling, licensing and hardware support than by fundamental differences in capability. The most recent shift is open-vocabulary detection. Models such as OWL-ViT, released by Google researchers in 2022, and Grounding DINO, published in 2023, are trained jointly on images and text and can detect objects described by arbitrary phrases, such as "a yellow pallet jack" or "a person in a high-visibility vest," without having been trained on that specific category. Paired with promptable segmentation models such as Meta's Segment Anything, released in 2023, they make it possible to bootstrap a detector for a new object type in hours rather than weeks. They remain substantially heavier than closed-vocabulary real-time detectors and are more often used for labelling data offline or for occasional queries than in a robot's tight control loop, but that boundary is moving. Table 2 compares the main families as they are encountered in robotics practice. Table 2. Main families of image object detectors as used on mobile robots. Family Representative examples Structure Strengths for robotics Limitations Two-stage Faster R-CNN, Mask R-CNN Propose regions, then classify and refine High accuracy; natural extension to masks Slower; heavier on embedded hardware Single-stage CNN YOLO lineage, SSD, RetinaNet Dense prediction over a grid in one pass Real-time on embedded GPUs; mature tooling Needs duplicate suppression; small objects harder Transformer set prediction DETR, Deformable DETR, RT-DETR Predicts a set of objects directly No hand-tuned suppression; strong on crowded scenes Heavier training; hardware support still maturing Open-vocabulary OWL-ViT, Grounding DINO Image and text embeddings matched New categories from text prompts Much heavier; lower precision on narrow domains Measuring whether a detector is good Detection accuracy is usually reported as mean average precision, or mAP, and it is worth understanding what this number does and does not tell you. A detection is counted as correct if its predicted box overlaps a ground-truth box of the same class sufficiently, where overlap is measured by intersection over union: the area of the two boxes' intersection divided by the area of their union. An intersection over union of 0.5 is a loose match; 0.75 is a tight one. For a given class, as you lower the confidence threshold you accept more detections, catching more true objects (raising recall) but also admitting more false positives (lowering precision). Average precision summarises the whole precision-recall trade-off as a single number between zero and one. Mean average precision averages it over classes, and in the convention established by the Microsoft COCO benchmark, introduced in 2014 with eighty everyday object categories, it is also averaged over intersection-over-union thresholds from 0.5 to 0.95. A high COCO mAP is a good sign that an architecture is capable. It says almost nothing about how a particular trained model will perform in a particular warehouse. COCO's images are photographs taken by people, mostly in good light, with the subject usually near the centre and at a moderate distance. A robot's images are taken from knee height, often in poor or uneven light, with motion blur, at oblique angles, with objects frequently cut off by the edge of the frame. COCO contains people but not pallets, forklifts or roll cages. A model trained on COCO and evaluated on warehouse images will usually perform far worse than its benchmark figure suggests, and the only reliable measure of a detector's fitness for a deployment is its precision and recall on a test set collected from that deployment, or one very like it. The metric itself also needs adjusting for robotics. Average precision weighs all errors in a class equally, but a robot does not. Missing a person two metres ahead of the robot is a far more serious error than missing one twenty metres away behind a rack. A useful practice is to report recall separately for objects inside the robot's stopping envelope and to set the operating confidence threshold to achieve a target recall there, accepting whatever false-positive rate results. False positives make the robot hesitant and slow; false negatives near the robot make it dangerous. From boxes to positions in space A bounding box in an image is not, by itself, useful for navigation. The robot needs to know where the object is on the floor. Depth cameras make this straightforward in principle, since the camera supplies a depth for every pixel, but there are pitfalls. The naive approach takes the depth at the centre of the bounding box and back-projects that pixel to a three-dimensional point. This fails whenever the centre of the box does not lie on the object, which is common: the centre of the box around a person walking sideways may fall between their legs, on the floor far behind; the centre of the box around a forklift may fall in the empty space beneath the mast. A more robust approach collects all depth pixels within the box, or within the object's segmentation mask if one is available, and takes a robust statistic such as the median or a low percentile of their distances, on the reasoning that the object is usually the nearest substantial surface within its own box. Better still is to cluster the three-dimensional points inside the box and choose the cluster most consistent with the expected size of the class. Once a three-dimensional point cloud for the object is in hand, it can be transformed into the robot's base frame and then the map frame, and summarised as a position, an approximate footprint and, if the object is tracked over time, a velocity. For safety-critical classes, the footprint should be inflated to cover what the camera cannot see: a person seen from the front still has a back, and a forklift seen from the side still has forks extending out of view. There is a parallel line of work on detecting objects directly in three dimensions, either from depth images or from lidar point clouds, with networks that output oriented three-dimensional boxes. This is standard in autonomous driving, where large labelled lidar datasets exist. In warehouse robotics it is less common, partly because labelled datasets are scarce and partly because the combination of a mature two-dimensional detector with depth back-projection works well at the short ranges indoor robots care about. Tracking: detection with memory A detector that runs independently on every frame has no memory. It will report a person at slightly different positions in consecutive frames because of noise, miss them entirely in a frame where they are partly occluded, and have no idea whether the person in this frame is the same one as in the last. For navigation this is inadequate. A planner needs to know not just where people are but which way they are moving and how fast. Multi-object tracking supplies the memory. The simplest effective scheme, published as SORT by Alex Bewley and colleagues in 2016, maintains a Kalman filter for each tracked object that predicts its position in the next frame, matches new detections to predictions by overlap, updates matched tracks, starts new tracks for unmatched detections, and deletes tracks that go unmatched for too long. DeepSORT added an appearance descriptor so that objects could be re-identified after occlusion, and ByteTrack, published in 2022, improved robustness by matching low-confidence detections to existing tracks rather than discarding them, on the reasoning that a weak detection near where a person is expected to be is probably that person. For a mobile robot the most natural place to track is not the image but the floor. Image-space tracking is confused by the robot's own motion, which makes stationary objects appear to move across the image. Projecting detections onto the floor in the map frame before tracking removes the robot's ego-motion from the problem and yields velocities in metres per second, directly usable by a planner. It is the same prediction-and-correction logic of Chapter 1, applied to each object. Running on a robot A detector that runs at thirty frames per second on a data-centre graphics card may run at two on the computer a battery-powered robot can carry. Embedded deployment is its own discipline. The dominant embedded platform for vision-heavy mobile robots is NVIDIA's Jetson family, currently built around the Orin system-on-module in several sizes, with the larger Thor modules aimed at more demanding humanoid and mobile-manipulation workloads. Intel and AMD processors with integrated graphics or neural accelerators, and dedicated vision accelerators from companies such as Hailo, are common alternatives. On all of these, the same techniques make detection fast enough. The network is exported from its training framework to an optimised inference runtime, such as NVIDIA's TensorRT, that fuses operations and selects efficient kernels for the specific hardware. Its weights and activations are quantised from 32-bit floating point to 16-bit floating point or 8-bit integers, which typically costs little accuracy if done with care and calibration data, and can multiply throughput several times over. The input resolution is chosen as low as the smallest important object allows: a person at ten metres must still occupy enough pixels to be detected. And the smallest architecture variant that meets the accuracy requirement on the deployment's own test set is chosen, rather than the largest that fits. Latency matters as much as throughput. A detection that arrives 150 milliseconds after the image was captured describes a world the robot has already moved through; at 1.5 metres per second, the robot has travelled more than twenty centimetres. The perception pipeline must stamp every detection with the capture time of its source image and transform it using the robot's pose at that time, as Chapter 1 emphasised, and the tracker must predict detections forward to the present before they reach the planner. The data problem The single largest determinant of a detector's performance in a warehouse is not its architecture but its training data. Pallets come in standard designs, such as the European EUR pallet, the North American 48-by-40-inch GMA pallet and assorted plastic pallets, but they are loaded with every imaginable product, wrapped in every kind of film, damaged in every way. People wear different uniforms in different facilities. Lighting varies from bright LED high-bays to dim mezzanines. A detector trained in one facility will often lose a meaningful fraction of its recall when moved to another. Three strategies help. The first is simply to collect and label images from the target environment, which remains the most reliable approach and is made much cheaper by open-vocabulary models and promptable segmentation that can pre-label images for human correction. The second is synthetic data: rendering warehouse scenes in simulators such as NVIDIA Isaac Sim with randomised lighting, textures, object placement and camera positions, so that the detector learns features robust to that variation. Synthetic data rarely replaces real data entirely, but a mixture often outperforms either alone. The third is to monitor the deployed fleet for low-confidence detections and disagreements between sensors, for example a depth cluster with no detection, or a detection with no depth support, and to route those images back for labelling. This closes the loop between deployment and training and is how mature fleets keep improving. A detector is the robot's vocabulary. It determines which distinctions the robot can draw between the things it sees. The rest of the perception system, the localization, the mapping and the treatment of dynamics, can only act on distinctions the detector makes. A robot that cannot tell a person from a pallet will either treat everyone as a pallet, which is dangerous, or every pallet as a person, which is uselessly slow. Chapter 4: Knowing Where You Are Before a robot can build a map, it helps to understand the simpler problem of using one. Suppose the warehouse has already been mapped, accurately and completely, and the map does not change. The robot is placed somewhere on the floor. Where is it? This is localization, and although it is easier than SLAM, it contains most of the conceptual difficulties of SLAM in miniature, and a great deal of what goes wrong with deployed robots goes wrong here. Dead reckoning and its drift The first source of information about where a robot is comes from the robot itself. Wheel encoders count rotations of the drive wheels; multiplied by the wheel circumference, they give distance travelled by each wheel; the difference between the left and right wheels on a differential-drive robot gives the change in heading. Integrating these increments over time yields an estimate of the robot's pose relative to where it started. This is odometry, a modern form of the dead reckoning that ships' navigators used for centuries before satellite positioning. Odometry has two virtues that make it indispensable. It is smooth, changing continuously without the jumps that sensor-based corrections can introduce, and it is available at high rate, often hundreds of times a second, with negligible latency. A robot's low-level motion control almost always runs on odometry. Its vice is drift. Every small error in each increment is integrated into the pose and never removed. A wheel diameter that is wrong by half a per cent produces a half-per-cent error in every distance. A small difference between the effective diameters of the left and right wheels, from uneven tyre wear or an uneven load, produces a steady error in heading that, integrated over distance, makes the robot believe it is driving straight when it is curving gently. Heading errors are particularly damaging because their effect on position grows with distance travelled: a heading error of one degree, sustained over a fifty-metre aisle, displaces the end of the aisle by nearly ninety centimetres. And wheels slip, on polished or dusty floors, when accelerating hard, when crossing expansion joints and dock plates, in ways the encoders cannot detect because the wheel is still turning. An inertial measurement unit, or IMU, helps. Its gyroscopes measure rotation rate directly, independent of wheel slip, and a modern micro-electromechanical gyroscope of the kind found in a robot's control board can measure heading changes over short periods more accurately than the wheels can. Its accelerometers measure linear acceleration, though integrating acceleration twice to get position drifts far too quickly to be useful on its own. Fusing wheel odometry with gyroscope heading, typically in an extended Kalman filter, is standard practice and substantially reduces heading drift. In the ROS ecosystem, the widely used robot_localization package provides exactly this fusion. But even fused odometry drifts without bound. To stay localised over a shift, the robot must compare what it senses against the map. The Kalman filter The Kalman filter, introduced by Rudolf Kálmán in 1960 and used in the Apollo navigation computers within the decade, is the Bayes filter of Chapter 1 for the case where everything is Gaussian. The belief about the robot's pose is a mean and a covariance. The prediction step moves the mean according to the motion model and adds the motion noise to the covariance, so the uncertainty grows. The correction step takes a measurement, compares it with what the current mean predicts, and moves the mean towards the measurement by an amount set by the Kalman gain, which weighs the uncertainty of the prediction against the uncertainty of the measurement. If the prediction is very uncertain and the measurement is precise, the estimate moves most of the way to the measurement. If the prediction is precise and the measurement noisy, it barely moves. The covariance shrinks accordingly. The Kalman filter is exact only for linear models, and robot motion is not linear: driving forward a metre moves the robot in a direction that depends on its heading, and the relationship involves sines and cosines. The extended Kalman filter handles this by linearising the models around the current estimate at each step. This works well when uncertainty is small relative to the curvature of the models, and it fails, sometimes catastrophically, when uncertainty is large, because the linear approximation is then poor. The unscented Kalman filter, which propagates a small set of carefully chosen sample points through the true nonlinear models, is often more accurate at similar cost. For localization against a map, the Kalman filter's real limitation is not linearisation but its assumption that the belief has a single peak. A robot in a long aisle of identical racks may genuinely be in one of several places, any of which explains what it sees equally well. A single Gaussian cannot represent "probably here, or possibly three bays further along, or possibly in the mirror-image aisle on the other side of the building." It must pick one, and if it picks wrongly, the filter has no way to recover. Particle filters and Monte Carlo localization The particle filter solves this by abandoning a parametric description of the belief altogether. It represents the belief as a large set of particles, each a hypothesis about the robot's pose, typically a few hundred to a few thousand of them. Where particles are dense, the robot is likely to be. The prediction step moves every particle according to the odometry, adding a random perturbation drawn from the motion noise, so the cloud spreads out. The correction step weighs each particle by how well the current sensor reading matches what the robot would expect to see from that particle's pose, given the map. A particle sitting where the laser scan lines up neatly with the walls on the map gets a high weight; a particle sitting where the scan cuts through walls gets a low one. Finally the filter resamples: it draws a new set of particles from the old, with probability proportional to weight, so that well-supported hypotheses multiply and poorly supported ones die out. Applied to robot localization this is called Monte Carlo localization, introduced by Frank Dellaert, Dieter Fox, Wolfram Burgard and Sebastian Thrun in 1999. Its adaptive variant, which grows the particle count when the belief is spread out and shrinks it when the belief is concentrated, is the algorithm behind AMCL, the default localization module in the ROS navigation stack and its ROS 2 successor Nav2. A very large number of warehouse and service robots in service today localise with some descendant of it. Particle filters can represent multiple hypotheses, which means they can, in principle, solve global localization: starting with particles spread uniformly over the whole map and letting the evidence concentrate them. They can also, if a small fraction of particles is continually injected at random poses, recover from the kidnapped robot problem, in which the robot is picked up and moved, perhaps by a technician, without its odometry knowing. Both capabilities are fragile in large, repetitive buildings, because the number of particles needed to cover the space densely enough to catch the true pose grows with the area, and because repetitive structure means many wrong hypotheses look as good as the right one for a long time. Matching scans to maps The heart of both filters is the sensor model that scores how well a reading fits a hypothesised pose, and in practice this means comparing a scan with the map. For planar lidar, the standard approach in AMCL is the likelihood field model. The map is preprocessed so that every cell stores its distance to the nearest occupied cell. To score a scan from a hypothesised pose, each scan endpoint is projected into the map and looked up; endpoints that land on or near walls score well, endpoints that land in open space score poorly. A mixture with a uniform component accounts for random readings, and another component accounts for readings that hit unmapped obstacles short of the wall. The model is fast, smooth and tolerant of small errors, which makes it work well in practice despite ignoring a good deal of physics. A different approach, used heavily in SLAM and in some localization systems, is scan matching: rather than scoring many hypotheses, directly search for the single pose that best aligns the current scan with the map or with a previous scan. The iterative closest point algorithm, introduced in 1992 by Paul Besl and Neil McKay and independently by Yang Chen and Gérard Medioni, alternates between pairing each point in the scan with its nearest neighbour in the reference and solving for the rigid transformation that best aligns the pairs. It converges quickly when started close to the answer and can fail badly when started far from it. Correlative scan matching, which exhaustively evaluates poses on a grid within a search window, is more robust to poor initialisation and is the core of several widely used SLAM systems. Depth cameras can be used for localization in the same way, by projecting their point clouds onto the floor plane to produce a pseudo-laser scan and feeding that into AMCL. This works, but depth cameras have narrower fields of view than lidar, typically under ninety degrees horizontally against two hundred and seventy or more for a safety lidar, and a narrow field of view makes localization much less well constrained: a robot facing straight down an aisle sees only the end wall and a sliver of rack on either side. Visual features offer a richer alternative, as the next chapter explains. Perceptual aliasing and the warehouse Warehouses are close to a worst case for localization, for a reason that is easy to state. Localization works by finding the place on the map where the current observations fit, and it works well when only one place fits. Warehouses are built to be uniform. Rack bays are identical. Aisles are identical. A robot in the middle of aisle seven sees what it would see in the middle of aisle eight, and what it would see two bays further along. This is perceptual aliasing, and it means that the sensor model, faced with a scan from the middle of an aisle, assigns similar high likelihoods to many distinct poses. Odometry is what keeps the robot from becoming lost in this situation: as long as the particle cloud is concentrated before the robot enters the aisle, odometry carries it through, and the aisle's side walls keep the lateral position and heading tight. The longitudinal uncertainty grows along the aisle and is collapsed when the robot reaches the end and sees the cross-aisle. This works, but it means that the robot's localization quality varies strongly with where it is, and a robot that suffers a wheel-slip event midway down a long aisle may emerge at the end with its longitudinal estimate off by a bay or more and a particle cloud too confident to correct it. The problem is compounded when the contents of the racks change. If the map was built when the lower bays were full of pallets, and the robot later drives past them empty, the scan sees through to the back of the rack and matches the map poorly everywhere. If pallets are staged in a cross-aisle where the map shows open floor, the robot's view of the cross-aisle's far wall is blocked. Each of these reduces the evidence available for localization at exactly the places the robot needs it. Cameras offer a partial remedy for aliasing that lidar cannot. Even where the geometry of two aisles is identical, their appearance often is not: the signage at the aisle end, the colour of the product in the bays, the position of a fire extinguisher or a first-aid station, the number painted on a column. Visual place recognition exploits these differences. The robot stores compact appearance descriptors of images taken at known poses during mapping, and when its localization is uncertain, or after a restart, it computes a descriptor for its current view and retrieves the most similar stored images, which suggest where it might be. Those candidate poses are then verified geometrically, by checking whether the depth or laser scan from each candidate matches the map. Classical systems used bags of visual words, described in the next chapter; modern ones increasingly use descriptors learned by neural networks, which are more robust to changes in lighting and viewpoint. Visual place recognition does not replace scan matching for precise localization, but as a way of generating good hypotheses it can turn a slow, uncertain global localization into a fast and confident one. Its weakness is the mirror image of its strength: appearance changes more readily than geometry, and the product in the bays that distinguished two aisles last week may have been replaced by something else. Engineering the environment Faced with these difficulties, many deployed systems sidestep pure natural-feature localization by adding artificial landmarks to the building, and it is important to recognise this as a legitimate engineering choice rather than a failure. The robots developed by Kiva Systems, which Amazon acquired in 2012 and which became the basis of its warehouse robot fleet, navigate a grid of two-dimensional barcodes fixed to the floor; a downward camera reads each code as the robot passes over it, giving an absolute position fix, and odometry carries the robot between codes. This is extraordinarily reliable and makes localization almost trivial, at the cost of installing and maintaining thousands of floor markers and restricting robots to the grid. Laser-guided vehicles, a decades-old technology in automated forklifts and tuggers, triangulate against retroreflective targets mounted on walls and columns at known positions. Visual fiducial markers, such as the AprilTag system developed at the University of Michigan, can be mounted on rack ends and read by an ordinary camera, giving the robot an unambiguous identification of where it is at each aisle entrance. The case for natural-feature navigation, which is what most autonomous mobile robots sold today advertise, is that it avoids infrastructure, allows robots to be deployed in days rather than weeks, and lets them go anywhere on the floor rather than only along predefined routes. The price is that localization must cope with aliasing and change using only the building's own structure. In practice many deployments use a hybrid: natural-feature localization for the bulk of the floor, augmented by a small number of fiducials in the places where natural features are most ambiguous or most changeable, such as long uniform aisles and dynamic staging areas. A good perception engineer asks not "how do we avoid markers?" but "where does the building's own structure fail to tell the robot where it is, and what is the cheapest way to fix that?" What localization teaches about SLAM Localization with a known map exposes, in a simpler setting, the three ideas that dominate the rest of this book. First, the robot's estimate is only as good as its account of its own uncertainty; an overconfident filter is more dangerous than a merely inaccurate one. Second, the information available for estimation varies enormously from place to place, and good systems are designed around the places where it is scarce. Third, the assumption that the map is correct and fixed is the weakest link: in a warehouse, the map is always, to some degree, wrong, and every algorithm that relies on it must tolerate the gap. SLAM removes the assumption that the map is given at all. It is to that problem the next chapter turns. Chapter 5: SLAM, Building the Map While Standing On It The previous chapter assumed the robot had a map. Where did the map come from? Someone had to build it, and the obvious way to build a map is to drive a robot around with its sensors running and stitch together what it sees. But stitching requires knowing where the robot was when it saw each thing, and knowing where the robot was requires a map. This is the chicken-and-egg structure that gives simultaneous localization and mapping its name and its difficulty. Neither the map nor the trajectory can be estimated well on its own; they must be estimated together. Why the problem is joint Imagine driving a robot with perfect sensors but imperfect odometry around a rectangular warehouse. At the start, it sees the first wall and records it. It drives a few metres; its odometry says it moved four metres, though it actually moved 4.05. It records what it sees now at a position that is five centimetres off. After a hundred metres of such steps, with heading errors compounding, the robot's estimate of where it is may be off by a metre or more, and every observation it has recorded along the way inherits the error of the pose at which it was made. The map is warped in exactly the shape of the trajectory error. The insight that founded SLAM as a field, set out in work by Randall Smith, Matthew Self and Peter Cheeseman in the late 1980s, is that these errors are not independent. The error in the position of every landmark the robot has seen is correlated with the error in the robot's pose at the time it saw it, and therefore with every other landmark seen from nearby poses. If the robot later learns that one landmark is somewhere slightly different from where it thought, that information should propagate, through the correlations, to correct the robot's current pose and every related landmark. A correct SLAM estimator must therefore track not just each quantity's uncertainty but the correlations between all of them. The most dramatic illustration of this is loop closure. When the robot completes its circuit of the warehouse and returns to the first wall, it recognises it. Its odometry says it is a metre away from where it started; its eyes say it is exactly where it started. That single recognition carries enormous information. It reveals the accumulated error of the whole loop, and because the errors are correlated, the estimator can distribute the correction backwards along the entire trajectory, pulling every recorded pose and every mapped observation into a consistent shape. A SLAM system that cannot close loops will build maps that drift without bound; one that closes them reliably can map buildings of almost any size. From filters to graphs The first practical SLAM systems, through the 1990s and early 2000s, applied the extended Kalman filter to a state vector containing the robot's pose and the positions of every landmark. This EKF-SLAM handles correlations correctly, but its covariance matrix grows with the square of the number of landmarks and each update touches every entry, so it becomes intractable beyond a few hundred landmarks. Its linearisations also accumulate errors that make it inconsistent over long runs. Particle filters offered an alternative. Michael Montemerlo, Sebastian Thrun and colleagues' FastSLAM, published in 2002, exploited the observation that if the robot's trajectory were known exactly, the landmarks would be independent of each other, so each particle could carry its own trajectory hypothesis and its own small, independent landmark estimates. Giorgio Grisetti, Cyrill Stachniss and Wolfram Burgard applied a refined version of this idea to occupancy grids in GMapping, published in 2007, which for a decade was the default way to build a two-dimensional laser map with ROS. Particle-filter SLAM is elegant, but it struggles to close large loops, because the particles carrying the correct trajectory may have been resampled away long before the loop is closed. The approach that won, and that underpins nearly every serious SLAM system built in the last fifteen years, treats the problem as one of optimisation over a graph. The idea goes back to a 1997 paper by Feng Lu and Evangelos Milios, but it became practical only when efficient sparse solvers and good front-end algorithms matured around 2010. In pose-graph SLAM, each node in the graph is a pose of the robot at some moment, usually sampled every metre or so of travel or every few degrees of rotation; these sampled poses are called keyframes or nodes. Each edge between two nodes is a constraint expressing a measured relationship between them, with an uncertainty: odometry gives constraints between consecutive nodes, and scan matching or visual feature matching between non-consecutive nodes gives additional constraints, the loop closures. The SLAM problem becomes: find the set of poses that best satisfies all the constraints simultaneously, weighting each by its certainty. This is a nonlinear least-squares problem, solved by iterative methods such as Gauss-Newton or Levenberg-Marquardt. Because each constraint involves only two nodes, the problem is extremely sparse, and sparse linear algebra solves it efficiently for graphs of tens of thousands of nodes. The more general factor graph formulation, developed and popularised by Frank Dellaert and Michael Kaess, among others, allows constraints involving any number of variables and any kind of measurement, including landmark positions, IMU readings, GPS fixes and calibration parameters. Libraries such as GTSAM, from Dellaert's group at Georgia Tech, and g2o, from Rainer Kümmerle, Grisetti and colleagues, provide the machinery, and incremental solvers such as iSAM2 update the solution efficiently as new measurements arrive rather than resolving from scratch. Front end and back end A modern SLAM system divides cleanly into two parts, a division that helps both in understanding the systems and in diagnosing their failures. The front end turns raw sensor data into constraints. It tracks the robot's motion from frame to frame, decides when to create a new keyframe, detects candidate loop closures by recognising previously visited places, and verifies them geometrically. It is where all the sensor-specific engineering lives, and it is where most failures originate: a wrong loop closure, matching aisle seven to aisle eight, is a front-end error. The back end takes the constraints and finds the most consistent poses and map. It is mathematically principled and largely sensor-independent. Its main vulnerability is that standard least-squares optimisation assumes every constraint is roughly right. A single wrong loop closure, given full weight, will drag two distant parts of the map together, folding the map like a crushed tin can. Robust back ends address this with cost functions that grow more slowly than the square of the error for large residuals, so that a constraint wildly inconsistent with the rest is effectively down-weighted, or with explicit mechanisms such as switchable constraints that let the optimiser turn off loop closures that do not fit. In the repetitive geometry of a warehouse, where false loop closures are a constant risk, this robustness is not optional. The danger is concrete. Consider a robot mapping a block of twenty identical aisles. It drives down aisle three, along the cross-aisle, and up aisle four. Its front end, searching for loop closures, compares the current scan from the middle of aisle four with stored scans and finds an excellent match with one taken in the middle of aisle three: the same rack uprights, the same beam heights, the same spacing. Geometrically, the match is nearly perfect. If accepted, it tells the optimiser that the robot is now where it was a few minutes ago, in aisle three, and the optimiser, honouring the constraint, will try to drag the two aisles on top of each other. Defences operate at several levels. The front end checks whether a candidate closure is plausible given the current uncertainty: if odometry is confident that the robot is three metres to the side of the matched pose, a match requiring a three-metre jump is suspect. It requires a candidate to be confirmed by several consecutive matches, not one, so that a sequence of observations along the aisle, including its ends, must agree. It looks for distinctive features, such as the cross-aisle's far wall, a column, or a fire door, that break the symmetry, and gives more credence to matches that include them. And the back end, if a wrong closure slips through anyway, uses a robust cost so that the single wrong constraint, fighting against hundreds of consistent odometry and correct loop-closure constraints, loses. In practice, careful commissioning adds one more defence: an engineer reviews the finished map for doubled walls, bent aisles and other signs of a false closure before it is put into service, because a corrupted map caught at commissioning costs an hour, while one caught after deployment costs much more. Laser SLAM in practice For two-dimensional mapping with a planar lidar, which remains how most warehouse robot maps are actually built, two open-source graph-based systems dominate. Cartographer, released by Google in 2016 and described by Wolfgang Hess, Damon Kohler, Holger Rapp and Daniel Andor in a paper at that year's International Conference on Robotics and Automation, builds small local occupancy grids called submaps by matching consecutive scans, and runs a background search that matches scans against older submaps to find loop closures, using a branch-and-bound search that makes exhaustive correlative matching fast enough for real time. Google later stopped active development, and the project is now maintained by its community. slam_toolbox, developed by Steve Macenski and colleagues and described in a 2021 paper in the Journal of Open Source Software, has become the default two-dimensional SLAM system in the ROS 2 navigation stack. It builds on the Karto scan matcher and a sparse pose-graph back end, and it was designed explicitly for the commercial use case: mapping very large spaces, continuing to refine a map across multiple sessions, merging maps, and running in a lifelong mode in which the map is updated during normal operation rather than frozen after an initial survey. Visual SLAM Cameras offer something lidar does not: an enormous amount of appearance information, the colours and textures and distinctive markings of the scene, which can make places recognisable where geometry alone is ambiguous. A rack-end label, a fire extinguisher, a painted column number or a poster in a break area are all invisible to a planar lidar but obvious to a camera. Visual SLAM systems fall into two broad families. Feature-based systems detect distinctive keypoints in each image, corners and blobs that can be found again from a different viewpoint, describe each with a compact descriptor, and match them across frames. The robot's motion and the three-dimensional positions of the points are then estimated together by minimising reprojection error, the distance in the image between where each point was observed and where the current estimate predicts it should appear. Optimising all camera poses and all point positions together in this way is called bundle adjustment, a technique inherited from photogrammetry. The most influential feature-based system is ORB-SLAM, published by Raúl Mur-Artal, J. M. M. Montiel and Juan Tardós in 2015, extended to stereo and RGB-D cameras as ORB-SLAM2 in 2017, and to visual-inertial and multi-map operation as ORB-SLAM3, led by Carlos Campos, in 2021. It uses the ORB feature, a fast binary descriptor, throughout: for tracking, for building the map, and for place recognition, which it performs with a bag of visual words index, the DBoW2 library of Dorian Gálvez-López and Tardós, that converts each keyframe into a histogram of quantised feature types so that candidate matches for the current view can be retrieved from thousands of keyframes in milliseconds. Direct systems, by contrast, skip keypoint extraction and estimate motion by directly aligning image intensities, minimising the difference in brightness between corresponding pixels. LSD-SLAM, published by Jakob Engel, Thomas Schöps and Daniel Cremers in 2014, and Direct Sparse Odometry, by Engel, Vladlen Koltun and Cremers, are the best-known examples. Direct methods use more of the image and can work in scenes with few distinctive corners, but they are sensitive to changes in lighting and exposure. With an RGB-D camera, the depth image allows visual SLAM to recover metric scale directly, which a single ordinary camera cannot. RTAB-Map, developed by Mathieu Labbé and François Michaud at the Université de Sherbrooke and described in a 2019 Journal of Field Robotics paper, is a widely used graph-based SLAM system that accepts RGB-D, stereo and lidar input, uses appearance-based loop closure detection with explicit memory management to bound computation in large environments, and outputs both occupancy grids for navigation and dense three-dimensional reconstructions. NVIDIA's Isaac ROS packages include a GPU-accelerated visual SLAM, cuVSLAM, aimed at robots built on Jetson hardware. A visual SLAM system that adds an IMU, a visual-inertial system, gains a great deal. The IMU constrains rotation tightly over short intervals, allowing tracking to survive brief periods of blur, darkness or featureless walls, and it makes gravity's direction observable, fixing the map's vertical axis. VINS-Mono, from Tong Qin, Peiliang Li and Shaojie Shen at the Hong Kong University of Science and Technology, published in 2018, and the visual-inertial mode of ORB-SLAM3 are prominent examples. Recent years have brought learned components into SLAM: neural feature detectors and matchers that are more robust to lighting changes than classical ones, systems such as DROID-SLAM, published by Zachary Teed and Jia Deng in 2021, that learn the whole tracking and optimisation pipeline, and dense map representations based on neural fields and Gaussian splatting that produce photorealistic reconstructions. These are active research directions. In warehouse deployments, classical geometric back ends with selectively learned front-end components remain the norm, because their failures are better understood and their computation is predictable. Comparing the main approaches The SLAM families encountered in warehouse robotics differ in what sensors they need, what kind of map they produce, and where they fail, as Table 3 summarises. Table 3. Main SLAM approaches used in indoor mobile robotics. Approach Typical sensors Map produced Representative systems Characteristic weaknesses 2D laser graph SLAM Planar lidar, wheel odometry 2D occupancy grid Cartographer, slam_toolbox Blind above and below scan plane; aliasing in uniform aisles Feature-based visual SLAM Mono, stereo or RGB-D camera, optional IMU Sparse 3D points, keyframe graph ORB-SLAM3, RTAB-Map Fails in low texture, poor light, fast motion Direct visual odometry and SLAM Mono or stereo camera Semi-dense or sparse 3D LSD-SLAM, DSO Sensitive to exposure and lighting changes Visual-inertial Camera plus IMU Sparse 3D, gravity-aligned VINS-Mono, ORB-SLAM3 Needs careful time sync and IMU calibration Dense RGB-D reconstruction Depth camera Volumetric surface model KinectFusion and descendants Heavy compute; assumes static scene Evaluating SLAM A SLAM system's output is a trajectory and a map, and the standard way to evaluate the trajectory, established with public benchmarks such as the TUM RGB-D dataset from Jürgen Sturm and colleagues in 2012, is to compare it with ground truth from an external motion-capture or surveying system. Two metrics dominate. Absolute trajectory error aligns the estimated trajectory with the ground truth and measures how far apart they are, capturing global consistency. Relative pose error measures the error in motion over fixed intervals, such as each metre travelled, capturing local drift. A system can have small relative error and large absolute error, if it drifts slowly and never closes loops, or the reverse, if it closes loops well but is noisy locally. These benchmarks are invaluable for comparing algorithms, but they are mostly recorded in offices, laboratories and city streets, over minutes, in largely static scenes. A warehouse deployment runs for months in a scene where a large fraction of what the camera sees is moved every day. That is a different problem, and Chapter 7 addresses it directly. First, however, the map itself deserves closer attention, because for navigation the representation that matters most is not the pose graph or the sparse visual landmarks but the occupancy grid that the planner reads. Chapter 6: Occupancy Grid Maps Of all the ways a robot can represent its surroundings, the occupancy grid is perhaps the least glamorous and the most useful. It has none of the visual richness of a dense three-dimensional reconstruction or the compactness of a sparse landmark map. It is simply a grid laid over the floor, each cell holding a number that says how likely it is that something solid occupies that patch of space. Yet nearly every mobile robot that moves through a warehouse today plans its path against an occupancy grid, or something directly descended from one. Understanding why requires understanding what the grid does well, and how a depth image becomes evidence written into it. The idea The occupancy grid was introduced by Hans Moravec and Alberto Elfes at Carnegie Mellon University in the mid-1980s, originally to fuse readings from rings of sonar sensors that were notoriously unreliable: a sonar ping reported the distance to the nearest echo somewhere within a wide cone, not the location of any particular surface. Elfes's insight was that rather than trying to extract walls and objects from such data, the robot could treat each reading as weak probabilistic evidence about a large number of small cells and let the evidence accumulate. The grid divides space into cells of fixed size. For a ground robot in a warehouse, a resolution of five centimetres is typical: fine enough to represent a rack upright or a pallet edge, coarse enough to keep the map tractable. Each cell holds a belief about whether it is occupied. The key simplifying assumption is that cells are independent: the probability that one cell is occupied does not depend on its neighbours. This is obviously false, since walls are continuous and objects are solid, but it makes the update so simple and fast that the resulting map is good enough for planning, and the errors it introduces are small compared with sensor noise. As Chapter 1 explained, each cell's belief is stored as log-odds, so that each new observation simply adds or subtracts a fixed amount. A cell that has never been observed sits at zero, meaning even odds. Observations that the cell is occupied push it positive; observations that it is free push it negative. To prevent cells becoming so certain that they can never change, the log-odds are clamped to a range, so that a cell that has been seen as occupied a thousand times can still be cleared by a modest amount of contrary evidence. That clamping turns out to matter enormously in a dynamic warehouse, and Chapter 7 returns to it. In code, the core of the update is almost embarrassingly short. L_OCC, L_FREE = 0.85, -0.4 # log-odds increments L_MIN, L_MAX = -2.0, 3.5 # clamping limits def update_cell(logodds, hit): logodds += L_OCC if hit else L_FREE return min(max(logodds, L_MIN), L_MAX) The intelligence lies not in the update but in deciding which cells to update, and with what. From a depth reading to evidence A single depth measurement says two things. It says that there is a surface at the measured distance along the pixel's ray, and it says that there is no surface between the sensor and that point, because if there were, the light would have stopped there. The second statement is as important as the first. A map built only from hits would accumulate obstacles but never clear them; it is the free-space evidence along each ray that lets a robot learn that a corridor is open, and that lets it erase an obstacle that has gone. The procedure that captures both statements is ray casting. For each depth reading, the robot computes the three-dimensional endpoint in the map frame, traces the straight line from the sensor's origin to that endpoint, and visits every grid cell the line passes through. The cells along the line, short of the endpoint, receive a free update. The cell containing the endpoint receives an occupied update. Efficient algorithms for stepping through grid cells along a line, such as Bresenham's line algorithm in two dimensions and the voxel traversal method published by John Amanatides and Andrew Woo in 1987 in three, make this fast enough to perform for many thousands of rays per frame. The rule that maps a measurement to evidence for each cell is the inverse sensor model. The simplest version, shown in the code above, adds a constant for hits and subtracts a constant for misses. A more careful version accounts for the sensor's error characteristics. Because stereo depth uncertainty grows with the square of distance, a reading from far away should spread a weaker occupied update over a range of cells around the measured endpoint, rather than a strong update into a single cell. Readings with no valid depth, the holes caused by black wrap or specular film, should generate no updates at all, neither occupied nor free, because they carry no information. And readings beyond the sensor's trusted maximum range can still be useful for clearing: if the camera saw nothing within six metres along a ray, the cells within six metres are probably free, even if the far reading is too noisy to trust as an obstacle. It is worth working through the numbers once, because they explain why mapping systems are engineered the way they are. A depth camera streaming at 848 by 480 pixels and thirty frames per second produces about twelve million depth readings a second. Casting a full ray for each, through five-centimetre cells out to a range of five metres, would mean visiting up to a hundred cells per ray, over a billion cell updates per second, far beyond what a robot's computer can spare for one sensor. So the depth image is first downsampled, often to a voxel grid of the same resolution as the map, which collapses the hundreds of readings that fall on one small patch of a box into a single point. The rays are then cast only from these representative points. A typical frame may shrink from four hundred thousand readings to a few thousand points with almost no loss of mapping information, because the discarded readings were nearly redundant observations of the same few cells. The same arithmetic applies to the map's size. A distribution centre with a floor of 200 by 100 metres, at five-centimetre resolution, needs four thousand by two thousand cells: eight million in all. Stored as one byte each, that is eight megabytes, comfortably within a robot's memory. Halving the resolution to two and a half centimetres quadruples the cell count to thirty-two million and quadruples the cost of every planning search over the map, for a gain in precision that the sensors' noise often cannot support. This is why five centimetres is a common compromise for warehouse floors, and why finer resolutions are usually reserved for small local maps around docking stations and pick locations, where the robot must position itself within a centimetre or two. From three dimensions to two A depth camera produces three-dimensional data, and a planar occupancy grid is two-dimensional. Collapsing one into the other requires decisions that have large consequences for safety. The first decision is how to separate the floor from obstacles. A camera pitched downward sees a great deal of floor, and every floor pixel is a depth reading that, naively projected, would mark a cell as occupied. The simplest approach is to discard all points below a small height threshold above the floor, a few centimetres, on the assumption that the floor is flat and the camera's extrinsic calibration is exact. Neither assumption holds perfectly. Warehouse floors have ramps at dock doors, drains, expansion joints and gentle slopes for drainage, and a small error in the camera's pitch makes the floor appear to tilt, so that distant floor rises above the threshold and appears as a wall. More robust approaches fit a plane to the floor points in each frame, using RANSAC, an algorithm that repeatedly fits a model to random small subsets of the data and keeps the model with the most supporting points, and measure obstacle heights relative to the fitted plane rather than to a fixed assumption. The second decision is which heights count as obstacles. For a robot of a given height, anything between the floor threshold and the top of the robot can cause a collision and should be projected into the grid. Anything above the robot's height, such as the underside of a rack beam or an overhead conveyor, can be safely ignored. Getting the upper bound right matters: set it too low and the robot will drive into a forklift's raised tines; set it too high and it will refuse to pass under a mezzanine it could clear. The third decision concerns negative obstacles: drops, edges and holes. A loading dock edge with the dock door open and no trailer present is a fall hazard. A depth camera looking at it sees the floor stop abruptly, and then either no returns or returns from far below. A system that only projects points above the floor into the grid will see nothing wrong, because there is nothing above the floor at the dock edge. Detecting drops requires explicitly reasoning about where the floor should be visible and is not, and treating persistent absence of floor returns in the robot's path as a hazard. In many deployments this is handled instead by mapping keep-out zones around dock edges and relying on dedicated sensors, but it illustrates a general point: an occupancy grid represents what the robot has evidence for, and some hazards produce evidence only by their absence. Beyond flat grids Planar grids lose information that matters for some tasks. A pallet overhanging a rack beam at a height of 1.2 metres and a pallet sitting on the floor occupy the same cell, but they constrain different robots differently. A robot carrying a tall load or an autonomous forklift lifting its mast needs to know what is at every height. The direct generalisation is a three-dimensional voxel grid, the same idea with cubic cells, but a dense voxel grid of a large warehouse at five-centimetre resolution would contain billions of cells, most of them empty air. OctoMap, published by Armin Hornung, Kai Wurm, Maren Bennewitz, Cyrill Stachniss and Wolfram Burgard in Autonomous Robots in 2013, solves this with an octree: a hierarchical structure in which a large cube is subdivided into eight smaller cubes only where needed, so that a large uniform region of free space or of solid wall can be stored as a single coarse node. OctoMap uses the same log-odds update and clamping as a planar grid and has been for years the standard three-dimensional occupancy representation in ROS. A different family of representations stores not occupancy but distance. A truncated signed distance field records, for each voxel near a surface, the distance to that surface, positive in front and negative behind, which allows surfaces to be reconstructed with sub-voxel precision. This was the basis of KinectFusion, from Richard Newcombe and colleagues at Microsoft Research in 2011, which first showed real-time dense surface reconstruction from a moving depth camera. Voxblox, published by Helen Oleynikova and colleagues at ETH Zurich in 2017, builds such a field incrementally and derives from it a Euclidean signed distance field giving, for every point in space, the distance to the nearest obstacle, which is exactly what a planner needs to assess clearance. NVIDIA's nvblox applies the same ideas on the GPU for real-time use on Jetson-based robots. Between two and three dimensions lie elevation maps and height maps, which store for each floor cell the height of the highest obstacle or the shape of the terrain. They are common in outdoor and legged robotics, and less so in warehouses, where the floor is flat and the important question is usually simply whether a robot's footprint can pass. Costmaps: grids that planners read A planner does not use the raw occupancy grid directly. It uses a costmap: a grid, aligned with the occupancy grid, in which each cell holds a cost for the robot's centre to be there. The ROS 2 navigation stack, Nav2, organises costmaps as a stack of layers, each contributing to the final cost, and this layered design has become a de facto standard for describing how robots combine different kinds of spatial knowledge. The static layer holds the prior map, typically built by SLAM during commissioning and stored as an image file with accompanying metadata. It represents the walls, columns and racks that are expected to be permanent. The obstacle layer and its three-dimensional sibling, the voxel layer, hold what the robot's sensors currently see, updated by ray casting from each new depth image or laser scan. They mark new obstacles and clear cells observed to be free. The spatio-temporal voxel layer, developed by Steve Macenski, takes a different approach suited to depth cameras: rather than clearing by ray casting, which is expensive for dense depth images, it lets observations decay over time unless refreshed and clears voxels that fall inside a sensor's current view frustum without a return, a design that handles the noisy, high-volume output of depth cameras efficiently. The inflation layer spreads cost outward from every obstacle. A robot is not a point; its body extends some distance from its centre. Rather than checking the full footprint against obstacles at every candidate position, the planner reasons about the robot's centre, and the inflation layer marks every cell within the robot's inscribed radius of an obstacle as lethal, because the centre cannot be there without collision, and assigns a decaying cost to cells somewhat further out, so that paths prefer to keep a margin from obstacles rather than skimming them. Further layers can encode anything else that affects where a robot should go: keepout zones such as fire exits and pedestrian walkways, speed zones in which the robot must slow down, preferred travel lanes, and, increasingly, the semantic and dynamic information that the next chapter discusses. The costmap is the point at which everything the robot knows about space, from its prior map, its sensors, its detections and its operators' rules, is reduced to a single grid of numbers a planner can search. What grids get right, and wrong The occupancy grid's enduring success rests on a few properties. It represents free space explicitly, which is what planners need: a path is a sequence of free cells. It handles noisy, ambiguous sensor data gracefully, because each reading is only weak evidence. It is indifferent to the type of sensor: lidar, depth camera and even sonar can all write into the same grid. And it is simple enough that its behaviour can be understood, debugged and certified. Its weaknesses are equally clear. The independence assumption ignores the structure of objects. Fixed resolution wastes memory on open floor and may be too coarse for fine clearances. Most importantly for a warehouse, the classical grid has no notion of what occupies a cell or how long it is likely to stay there. A wall and a parked pallet jack are both just occupied cells. The grid records evidence, accumulates it, and clears it only when contrary evidence arrives, which means its picture of the world lags reality whenever things move. In a building where things move constantly, that lag is the central problem, and solving it requires giving the map some understanding of time and of meaning. Chapter 7: When the World Moves Every technique in the last three chapters rests, to some degree, on the assumption that the world holds still while the robot moves through it. Localization assumes the map is right. SLAM assumes that a feature seen twice is the same feature in the same place. The occupancy grid assumes that repeated observations of a cell are independent evidence about a fixed truth. In a warehouse, all three assumptions are violated constantly, and not in a small way. On a busy shift, a large share of what a robot's sensors see near floor level may be things that were not there yesterday or will not be there tomorrow: pallets in staging lanes, carts, pallet jacks, roll cages, stacked empties, people and vehicles. This chapter is about how perception systems survive that. Its central argument is that the fusion of recognition and geometry is the key to robust mapping in dynamic spaces: a robot that can tell what things are can also make good guesses about how long they will stay, and that knowledge lets it decide which observations to build its map from, which to plan around, and which to forget. Three timescales of change It is useful to sort the contents of a warehouse by how quickly they change, because each timescale calls for a different treatment, as Table 4 sets out. At one extreme is static structure: the building's walls and columns, the racking, fixed conveyors, dock doors, permanent machinery. These change on the timescale of months or years, during reconfigurations, and when they change the change is planned and known in advance. Static structure is what a robot should localise against and what its prior map should contain. At the other extreme are dynamic objects: people and vehicles that are in motion while the robot observes them. They move on the timescale of seconds. They should never be written into a persistent map, never used as landmarks, and always tracked and predicted so that the robot can avoid them. Between the two lies the hardest category, the semi-static: objects that are stationary while the robot sees them but are moved between visits. A pallet set down in a staging lane may sit there for twenty minutes or two days. A pallet jack abandoned at an angle across an aisle may stay for an hour. A rack bay's contents change every time it is picked or replenished. These objects look exactly like static structure in any single observation, and they are what causes most of the trouble. A robot that maps them as permanent will plan around ghosts and localise against features that have gone. A robot that ignores them will drive into them. Table 4. Timescales of change in a warehouse and how a perception system should treat each. Category Examples Typical timescale Use for localization Treatment in map Static Walls, columns, racking, fixed conveyors Months to years Yes, primary landmarks Prior map; updated only by planned survey Semi-static Staged pallets, carts, rack contents, parked jacks Minutes to days Cautiously or not at all Separate layer with decay; change detection Dynamic People, forklifts, tuggers, other robots Seconds No Never persisted; tracked and predicted How motion corrupts estimation Moving objects damage perception in two distinct ways, and it helps to keep them apart. The first is corruption of the robot's own motion estimate. Visual odometry and scan matching estimate how the robot moved by finding the transformation that best aligns the current observation with a previous one. The implicit assumption is that whatever does not align was noise. When a forklift crosses the camera's view, its features move consistently with each other but inconsistently with the background. If the forklift occupies a small part of the image, robust estimators such as RANSAC, which find the motion that agrees with the largest consistent subset of matches, will treat the forklift's features as outliers and ignore them. If it occupies most of the image, as when it passes close in front of the camera, the largest consistent subset may be the forklift itself, and the robot will conclude that it has moved in the opposite direction from the forklift. This is the visual equivalent of sitting in a stationary train and feeling yourself move when the train beside you pulls out. The second is corruption of the map. Any object observed while stationary and written into a persistent map becomes, from the map's point of view, part of the building. Later, if it moves, two problems follow. The map now contains an obstacle that is not there, which may block paths the planner would otherwise use. And the place where the object used to be will look different, so that when the robot returns there, its observations do not match the map, its localization degrades, and loop-closure detection may fail to recognise the place at all. Conversely, a semi-static object that appears in a previously empty area will cause localization to match poorly too. There is a subtler version of the second problem. In repetitive environments, semi-static objects sometimes make places more distinctive. A distinctive arrangement of pallets at the end of aisle seven may be the only thing distinguishing it from aisle eight. A SLAM system will happily use that arrangement to close a loop. When the pallets move, the map has lost the very feature that held it together, and if pallets of a similar arrangement appear at aisle eight, the system may close a false loop that folds the map. Geometric defences The first line of defence uses geometry alone, without knowing what anything is. Robust estimation, already mentioned, rejects observations that are inconsistent with the dominant motion. It handles small moving objects well and large ones poorly. Ray-casting clearance in the occupancy grid, described in the last chapter, removes objects that move away, provided the robot observes the empty space where they were. This works naturally for the local costmap that the robot builds as it drives, where obstacles appear and vanish as they are seen and cleared. Its weakness is that it clears only what it sees: an obstacle that moves while the robot is elsewhere stays on the map until the robot returns and looks directly at the space. Clamping the log-odds of each cell, as Chapter 6 described, ensures that no cell becomes so confident that a modest amount of contrary evidence cannot flip it. The choice of clamping limits is a choice about how quickly the map responds to change: tight limits make the map responsive but noisy, loose ones make it stable but slow. Temporal decay treats evidence as perishable. Each cell's log-odds relaxes towards zero, the unknown state, over time unless refreshed by new observations. Objects that are seen repeatedly stay on the map; objects that are not seen fade. The spatio-temporal voxel layer described in Chapter 6 works this way. Decay is well suited to the short-term map that a robot uses for obstacle avoidance and is easy to tune: the decay time should be long enough that an obstacle briefly out of view, behind the robot or below the camera's field of view, is not forgotten before the robot has passed it, and short enough that objects that have left are forgotten before they cause the robot to make poor choices. More sophisticated approaches model change explicitly. Peter Biber and Tom Duckett, in work presented at the Robotics: Science and Systems conference in 2005, proposed maintaining several maps of the same environment at different timescales simultaneously, from a short-term map that tracks changes within minutes to a long-term map that reflects the state averaged over weeks, and showed that localization was more robust using a map whose timescale matched the change it encountered. Daniel Meyer-Delius, Maximilian Beinhofer and Wolfram Burgard proposed in 2012 modelling each cell's occupancy as a hidden Markov process with learned probabilities of transitioning between occupied and free, so that cells known to change often, such as a staging lane, are treated differently from cells that never change, such as a wall. Tomáš Krajník and colleagues' frequency-map enhancement, FreMEn, published in 2017, went further, modelling each cell's occupancy as a combination of periodic functions, capturing for example that a dock area is cluttered during the morning inbound shift and clear in the afternoon. These approaches are well studied in long-term autonomy research and are beginning to appear, in simplified form, in commercial systems. Semantic defences Geometric methods treat all occupied cells alike. They cannot tell, from one observation, whether a box-shaped obstacle is a building column that will never move or a pallet that will be gone in ten minutes. A detector can. This is where object detection stops being a separate subsystem and becomes part of mapping. The simplest semantic defence is masking. Before depth points or image features reach the SLAM system or the persistent map, any that fall on objects of a dynamic class, such as people, forklifts and other robots, are removed. DynaSLAM, published by Berta Bescos, José Fácil, Javier Civera and José Neira in 2018, did this in an ORB-SLAM2 pipeline, using Mask R-CNN to segment people and other potentially moving objects and excluding their features from tracking and mapping, combined with a geometric check for moving objects of classes the network did not recognise. It markedly improved tracking accuracy on dynamic sequences of the TUM benchmark relative to the original system. Masking costs little and is robust because it does not require the object to be moving at the moment of observation: a person standing still is masked just as a walking one is, which is correct, because they will move. Masking extends naturally to semi-static classes. A robot that detects pallets, carts and roll cages can exclude them from the observations it localises against, using only geometry that falls on static classes such as racking and walls. In a warehouse, this sounds dangerous, because it removes much of what the robot sees at floor level. But the racking is still there, the columns are still there, and these are exactly the features that will still be there next week. A localization system using fewer but more permanent features is often more reliable than one using many features that may vanish. A richer approach is to give the map itself semantic layers. Rather than a single occupancy grid, the robot maintains a static layer built from static-class observations, a semi-static layer in which each occupied region is associated with a detected object and a time last seen, and a dynamic layer that holds only the current tracked positions and predicted paths of moving agents. Each layer can have its own update and decay rules: the static layer barely changes and is used for localization; the semi-static layer decays over hours and is used for planning; the dynamic layer is rebuilt every frame. The costmap combines them, and each contributes in a way appropriate to its permanence. At the research frontier, three-dimensional scene graphs push this further. Systems such as Hydra, presented by Nathan Hughes, Yun Chang and Luca Carlone at MIT in 2022, build hierarchical representations in which the map contains not only geometry but objects, places, rooms and buildings as nodes in a graph, with relationships between them. A robot with such a representation can answer questions such as "which pallets in staging lane B have been there longer than a day?" or "has the layout of rack row twelve changed since last week?" Scene graphs are not yet standard in warehouse navigation, but they suggest where the fusion of recognition and mapping is heading: towards maps that model a building as a collection of things with properties and histories, not merely as a grid of probabilities. Lifelong mapping A map built once at commissioning and never updated decays in usefulness as the warehouse changes around it. Racks are added, conveyors relocated, staging areas redrawn, and with each change localization degrades a little in the affected region until someone notices and resurveys. Lifelong mapping systems instead update the map continuously during normal operation. The difficulty is that a map updated continuously from what the robot sees is also exposed continuously to everything the robot sees, including semi-static clutter. If the update is too eager, the map fills with pallets; if too cautious, it never reflects genuine changes. The pose graph also grows without bound if every new observation adds nodes. Practical lifelong systems therefore combine several mechanisms. They add new information to the graph only where it differs meaningfully from the existing map. They prune old nodes in regions that have been revisited, keeping the graph's size proportional to the area of the building rather than to the robot's total distance travelled, an approach studied in Aisha Walcott-Bryant and colleagues' dynamic pose-graph SLAM work at MIT in 2012. And they treat changes in static structure, which should be rare, as events to be confirmed, sometimes by multiple robots or by a human, before they are committed to the localization map. slam_toolbox's lifelong mode, mentioned in Chapter 5, implements a version of this for two-dimensional maps, and commercial autonomous mobile robot vendors generally maintain their own equivalents, often with a central server that collects map updates from the whole fleet, merges them, and redistributes a consensus map. Changes as information A final shift in perspective is worth making. In the classical view, change is noise: something the perception system must tolerate. In a well-designed warehouse system, change is also information, and often information someone else wants. A robot that notices a pallet has been sitting in a fire-exit lane for three hours has detected a safety violation. A robot that sees that a rack location the warehouse management system lists as full appears empty has detected an inventory discrepancy. A robot that finds an aisle repeatedly blocked at the same time each day has identified a workflow bottleneck. Each of these requires the same machinery as robust mapping: detecting objects, associating them with places, tracking how long they persist, and comparing what is seen with what is expected. A perception system that separates permanent structure from transient content is, almost as a by-product, a system that can report on the transient content. In mature deployments, this reporting can turn out to be worth a meaningful share of the robots' value. The robot that navigates a dynamic warehouse well, then, is not one that has learned to ignore change. It is one that has learned to classify it, to localise against what persists, to plan around what is present now, to forget what has gone, and to notice when something that should not move has moved. Chapter 8: From Maps to Motion A map is useful only because a robot can plan with it. Everything in the previous chapters, from the depth camera's noisy pixels to the semantic layers of a lifelong map, exists to give a planner a good enough picture of the world to choose where to go next. This chapter follows that picture into motion: how a robot decides on a route across a warehouse, how it follows that route while avoiding things its map did not predict, how it moves among people, and how all of this is reconciled with the safety standards that govern machines sharing floor space with workers. Two planners, two horizons Practically every mobile robot navigation system divides planning into two levels, because two different questions are being answered on two different timescales. The global planner answers the question: what route should I take from here to the goal, given what I know about the building? It works on the full costmap, or a coarse version of it, plans over the whole distance to the goal, and replans infrequently, perhaps once a second or when something significant changes. Its output is a path, a sequence of positions from the robot to the goal. The local planner, often called the controller, answers the question: what velocity command should I send to the motors right now to follow that path while avoiding collisions? It works on a small, rolling window of the costmap around the robot, perhaps a few metres on each side, updated at high rate from the latest sensor data, and it produces commands many times per second. It is responsible for reacting to the person who has just stepped into the aisle, which the global planner may not yet know about. This division mirrors the separation between the persistent map and the short-term obstacle layers described in Chapter 6. The global planner reasons mostly over the static and semi-static picture; the local planner reasons mostly over what the sensors are seeing this instant. Global planning The classic global planning algorithms are graph searches over the costmap's cells. Dijkstra's algorithm, published by Edsger Dijkstra in 1959, expands outward from the start in order of accumulated cost until it reaches the goal, guaranteeing the cheapest path. A*, published by Peter Hart, Nils Nilsson and Bertram Raphael in 1968, adds a heuristic estimate of the remaining cost to the goal, typically the straight-line distance, which focuses the search towards the goal and makes it much faster while preserving optimality as long as the heuristic never overestimates. On a costmap where every cell has a cost reflecting proximity to obstacles, these algorithms find paths that are short but also keep a sensible distance from racks and walls. Grid paths, however, are made of steps between neighbouring cells, and a differential-drive robot or, worse, a forklift with car-like steering cannot follow sharp zig-zags. Planners that account for the robot's kinematics search not over cells but over feasible motions. Hybrid A* searches over a lattice of continuous positions and headings using motion primitives the robot can actually execute, producing paths that respect minimum turning radii; it was developed at Stanford for the DARPA Urban Challenge in 2007. State lattice planners precompute a set of feasible motion segments and search over sequences of them. Nav2 provides several such options in its Smac planner family, alongside the simpler grid-based NavFn, and the choice among them depends largely on the robot's steering geometry. In a warehouse, the global planner's most important input is often not the geometry at all but the operators' rules. Robots should drive on the right side of wide aisles, use designated travel lanes, avoid pedestrian walkways, keep out of fire-exit routes, go slowly near pick stations, and not enter aisles where forklifts are working. These rules are encoded as costmap layers, as keep-out and speed-limit masks, or as a separate graph of permitted routes, and in many commercial deployments the robot does not plan freely across the floor at all but plans over a graph of lanes laid out during commissioning, falling back to free-space planning only to get around obstacles. This is not a failure of autonomy. It makes robot behaviour predictable to the people who work alongside them, which is itself a safety feature. Local planning and control The local planner must choose a velocity command that makes progress along the global path, keeps clear of obstacles, respects the robot's limits on speed and acceleration, and does all this in a few milliseconds. The dynamic window approach, published by Dieter Fox, Wolfram Burgard and Sebastian Thrun in 1997, set the template that many local planners still follow. At each control cycle, it considers the set of velocities the robot can reach within the next short interval given its acceleration limits, the "dynamic window," samples candidate velocity pairs within it, simulates each forward for a second or two, and scores the resulting trajectories by how close they bring the robot to the path and goal, how far they stay from obstacles, and how fast they go. The best-scoring command is sent to the motors, and the process repeats. Its descendant DWB is part of Nav2. Model predictive control generalises this by optimising a whole sequence of future commands against a cost function and a model of the robot's dynamics, executing only the first command and then re-solving. The timed elastic band planner, by Christoph Rösmann and colleagues, optimises a trajectory as a deformable band subject to time and kinematic constraints. Model predictive path integral control, MPPI, developed by Grady Williams and colleagues at Georgia Tech for aggressive autonomous driving, samples thousands of perturbed command sequences, simulates them in parallel, and computes a weighted average favouring the low-cost ones; its Nav2 implementation has become popular because it handles complex cost functions and different drive types well. Regulated pure pursuit, a refinement by Macenski and colleagues of a classic path-tracking method, is a simpler and very predictable controller that steers towards a point a fixed distance ahead on the path and reduces speed near obstacles and in tight turns, and it is widely used in industrial settings precisely because its behaviour is easy to anticipate. Above both planners sits a layer of decision logic: what to do when the path is blocked, when the robot is stuck, when localization confidence drops, when a goal becomes unreachable. Nav2 expresses this logic as behaviour trees, a structure borrowed from video-game artificial intelligence, in which tasks such as "follow path," "clear costmap," "spin in place to relocalise," "back up," and "wait" are composed into a tree that defines the robot's response to each situation. Most of the visible quality of a robot's behaviour in a crowded warehouse, whether it waits patiently, finds another route, or dithers, comes from these recovery behaviours rather than from the planners themselves. Moving among people A robot that avoids people only by treating them as obstacles, inflating them like any other cell in the costmap, will be safe in the narrow sense of not colliding with them, but it will behave badly. It will cut close in front of people who are walking, because it does not anticipate where they are going. It will freeze when a group crosses its path, because every candidate trajectory passes through someone's inflated footprint. It will make sudden, unpredictable movements as people's positions change frame by frame. Workers will learn to distrust it and, often, to work around it in ways that defeat its productivity. Human-aware navigation addresses this in three ways, each building on perception machinery from earlier chapters. The first is prediction. A person detected and tracked on the floor plane, as described in Chapter 3, has an estimated velocity, and the planner can reason about where that person will be over the next few seconds rather than only where they are now. Sophisticated learned predictors exist, but a 2020 study by Christoph Schöller and colleagues showed that a simple constant-velocity model was a surprisingly competitive baseline for short-horizon pedestrian prediction on standard benchmarks, which reflects the fact that over a second or two most people keep walking in the direction they were walking. In a warehouse, where workers often pause, turn sharply into a bay, or step backwards while handling a load, prediction must be paired with generous margins and with acknowledgement that it will often be wrong. The second is social cost. Rather than a uniform inflation around each person, the costmap can assign higher cost in front of a moving person than behind, and higher cost in the space a person is about to walk into than to their side. This encodes, crudely, the conventions people use with each other: do not cut in front, pass behind, keep to one side. The social force model, published by Dirk Helbing and Péter Molnár in 1995 to simulate pedestrian crowds, which treats people as particles repelled by each other and by obstacles and attracted by their goals, has inspired many such cost formulations. The third is legibility. A robot that signals its intentions clearly, by slowing early and visibly, by choosing a consistent side when passing, by projecting its intended path onto the floor with a light, or simply by following predictable lanes, is easier for people to share space with than one that is technically optimal but erratic. Legibility is not strictly a perception problem, but it depends on perception: the robot can signal only what it has decided, and it can decide well only about the people it has seen and tracked. Safety: what perception is allowed to do All of the perception described in this book, the depth cameras, the neural detectors, the SLAM systems, the semantic maps, shares one property that matters greatly when machines share a floor with people. None of it, in the ordinary implementation, is safety-rated. A neural network detector cannot currently be certified to detect a person with the reliability that functional-safety standards demand, and a SLAM system cannot guarantee that the robot knows where it is. For this reason, warehouse robots typically separate their perception into two channels. The navigation channel uses all the techniques of this book to plan good, efficient, socially sensible motion. The safety channel uses a small number of dedicated, certified sensors, most commonly safety-rated laser scanners from manufacturers such as SICK, Pilz and Omron, connected to a certified safety controller that can cut power to the drives independently of the main computer. The safety scanner monitors configurable protective fields: regions around the robot in which any detected object triggers a stop. The fields are switched according to the robot's speed and direction, so that a robot moving fast has a long protective field ahead of it and one moving slowly has a short one. A larger warning field outside it typically triggers a slowdown. The relevant standards for driverless industrial vehicles and autonomous mobile robots are ISO 3691-4, whose current edition was published in 2023, and, in North America, the ANSI/A3 R15.08 series, with Part 1 covering manufacturer requirements published in 2020 and Part 2 covering integration published in 2023. These standards require, among other things, that personnel detection meet a defined level of safety integrity, typically expressed as a performance level under ISO 13849, and that the integrator verify the stopping distance of the robot against its protective fields across its operating range. The relationship between the two channels is important to understand. The navigation channel's job is to ensure that the safety channel almost never has to act. A robot whose safety scanner triggers frequent emergency stops is a robot whose navigation perception is not doing its job: it is being surprised by obstacles it should have seen and planned around. Every unplanned stop costs productivity, and frequent stops lead workers and managers to pressure integrators to shrink protective fields, which erodes the margin the safety system exists to provide. Good navigation perception is therefore not in competition with safety; it is what makes a robust safety configuration commercially tolerable. The separation also clarifies the role of depth cameras. Planar safety scanners have the blind spots described in Chapter 2: overhanging loads, raised forks, low objects below the scan plane. Depth cameras see these hazards well, but are not normally safety-rated. Most deployments handle this by using depth cameras in the navigation channel to detect and plan around three-dimensional hazards, and by managing the residual risk through route design, speed limits in areas where such hazards occur, and operational rules. Safety-rated three-dimensional sensors exist and are becoming more common, and as they mature, the boundary between the two channels will shift. Fleets and traffic A single robot planning against its own map is the simplest case. Most warehouses run fleets, from a handful to many hundreds of robots, and fleets create a coordination problem that individual navigation cannot solve. Two robots approaching each other in a narrow aisle, each with a perfectly good local planner, may each decide to give way and end up in a polite standoff, or each decide to proceed and meet nose to nose. A cluster of robots converging on a busy pick station can create gridlock. Fleet management systems handle this by reserving resources centrally: allocating aisles, intersections and stations to robots for time windows, assigning one-way traffic in narrow aisles, and sequencing arrivals. The interface between fleet management and individual perception is a frequent source of trouble in practice. The fleet manager's picture of where robots are is only as good as each robot's localization, and a robot that is mislocalised by half a metre may believe it is outside a reserved intersection while actually inside it. Shared maps, discussed in the next chapter, are part of the answer; so is each robot's perception of other robots, which, as dynamic objects that move predictably and report their intentions over the network, are in some ways the easiest agents on the floor to plan around. Navigation, in the end, is the place where every error upstream becomes visible. A depth artefact becomes a phantom obstacle the robot stops for. A missed detection becomes a near miss. A localization error becomes a robot scraping a rack. A map that has not forgotten a moved pallet becomes a detour. Judging a perception system by how its robot moves is unfair to the perception engineers, who did not write the planner; but it is the judgement that matters. Chapter 9: From Prototype to Fleet There is a moment familiar to everyone who has built a mobile robot. The perception stack runs, the map is clean, the detector finds people and pallets, and the robot drives a loop of the test area flawlessly, again and again. It is tempting to believe the work is nearly done. In fact it has barely started. The difference between a robot that works in a demonstration and a fleet that works through a peak-season night shift is made up of hundreds of small failures, each rare, each specific to some combination of surface, lighting, layout and human behaviour, and each capable of stopping a robot, or a production line, at three in the morning. This chapter is about closing that gap. It is less about algorithms than about how perception systems are evaluated, tested, deployed and maintained, because in practice that is where the reliability of a warehouse robot is won or lost. What to measure Benchmarks in the research literature measure components: the mean average precision of a detector, the absolute trajectory error of a SLAM system, the accuracy of a depth camera at a stated range. These are necessary, but a fleet operator does not care about any of them directly. They care whether the robots complete their tasks, how often a person has to intervene, and whether anyone gets hurt. The metrics that matter in deployment are therefore system-level. Mission success rate is the fraction of assigned tasks the robot completes without help. Interventions per hour, or mean distance between interventions, counts how often a human must rescue, reposition or restart a robot; it is the single most informative number about a fleet's maturity, and the one most worth tracking over time. Unplanned stops, events in which the safety channel halted the robot, measure how often navigation perception failed to anticipate an obstacle. Localization confidence, summarised from the filter's own uncertainty estimates and the quality of scan-to-map matches, is a leading indicator: it degrades before robots actually become lost, and regions of the map where it is persistently low are regions where the map, the environment or the sensors need attention. These metrics should be broken down by location and by time. A fleet whose interventions are concentrated in one staging area has a mapping problem there. A fleet whose localization confidence drops every afternoon has a lighting problem, probably sunlight through a particular set of skylights or dock doors. A fleet whose unplanned stops rise in the weeks before a holiday peak has a clutter problem, because temporary storage spills into travel aisles. The aggregate number tells you whether things are getting better; the breakdown tells you what to fix. Component metrics remain essential for diagnosis. When interventions cluster somewhere, the engineer needs to determine whether the cause is depth artefacts, missed or false detections, localization drift, a stale map or a planner choice, and that requires being able to replay what each component saw and decided at the moment of failure. Logging and replay The most valuable piece of infrastructure in a perception team is often not a model or an algorithm but the ability to record exactly what a robot sensed and computed and to replay it offline. ROS 2 records data as bags, now commonly in the MCAP container format, which store time-stamped sensor messages, transforms, detections, costmaps and commands. Replaying a bag through a modified perception stack lets an engineer reproduce a failure, test a fix, and confirm that the fix does not break anything else. Recording everything all the time is impractical: a single robot with two depth cameras and a lidar can generate gigabytes per minute. Mature fleets therefore record a rolling buffer on each robot and persist it only when something interesting happens, such as an intervention, a safety stop, a localization confidence drop, or a disagreement between sensors, uploading the relevant window for analysis. The trigger conditions are themselves a perception design decision: they determine which failures the team will ever see. A curated library of such recordings becomes a regression suite. Every new version of the perception stack is replayed against it before deployment, and any scenario that previously worked and now fails blocks the release. Over time the library comes to encode the institutional memory of every way the robots have gone wrong, and it is one of the few defences against the classic failure of software improvement, which is that fixing one rare case quietly breaks another. Simulation and its limits Simulation allows testing at a scale and in conditions that the physical world cannot easily provide: thousands of variations of a scenario, rare and dangerous events, layouts that do not yet exist. Gazebo, maintained by Open Robotics and tightly integrated with ROS, and NVIDIA's Isaac Sim, built on its Omniverse platform with physically based rendering and sensor models, are the most widely used simulators for warehouse robotics. Both can simulate lidar, depth cameras and colour cameras, populate scenes with moving people and vehicles, and run the robot's real software stack against the simulated sensors. Simulation is particularly good at testing planning and behaviour logic, at generating synthetic training data for detectors, as Chapter 3 described, and at stress-testing multi-robot coordination. It is weakest at reproducing the sensor failures this book has emphasised. Simulated depth cameras, unless modelled with great care, do not produce flying pixels at object edges, multipath errors in corners, holes on black stretch wrap, or the specular chaos of clear film. Simulated floors do not have the wear patterns, wet patches and reflections of real concrete. A perception stack that has been tuned in simulation will typically meet real depth data for the first time and find it far worse. This sim-to-real gap can be narrowed with better sensor models, with noise injected from real recordings, and with randomisation of materials and lighting, but it cannot be closed entirely, and simulated testing of perception must always be followed by testing on real data. A deployment sequence Bringing a perception system into a new warehouse is best done in deliberate stages, each designed to surface a different class of failure before it can do harm. 1. Survey. Before any robot is deployed, an engineer walks the site, noting surfaces and lighting that may defeat the sensors: skylights and dock doors that admit direct sunlight, areas of black wrap or reflective packaging, polished or wet floors, mesh decking, glass partitions, ramps and dock edges. 2. Mapping. A robot, often driven manually, builds the initial SLAM map, ideally when the site is as empty as it will ever be, so that the map captures static structure rather than temporary clutter. The map is then reviewed and cleaned by hand: temporary objects erased, keep-out zones and lanes drawn, speed zones marked. 3. Shadow operation. Robots run their full perception stack while being driven manually or while following a human, without making their own decisions, and their localization, detections and planned paths are logged and compared with what actually happened. This exposes localization weak spots and detector blind spots before the robot is trusted to act. 4. Supervised autonomy. Robots operate autonomously in limited areas or at limited speeds, with staff on hand to intervene, and every intervention is logged and analysed. 5. Scaled operation. The fleet expands to full size and full speed, with the monitoring described above, and the regression suite grows with every new failure. None of these stages is novel, and it is tempting to skip them under schedule pressure. The failures they are designed to surface do not go away when skipped; they simply appear later, at scale, in production. Maps as managed assets In a small deployment, the map is a file on a robot. In a fleet, it is a shared asset that many robots depend on and that changes over time, and it needs to be managed with the same care as any other critical piece of infrastructure. That means versioning: every change to the map is recorded, with who made it and why, and any version can be restored. It means distribution: when the map changes, every robot receives the new version in a controlled way, so that the fleet does not operate on a mixture of old and new maps, which is a reliable way to produce baffling localization failures. It means merging: when several robots contribute observations to a lifelong map, as Chapter 7 described, their contributions must be aligned and reconciled, and conflicts resolved, ideally by a process that treats changes to static structure as requiring confirmation. And it means ownership: someone at the site, not only at the vendor, must know when the physical layout has changed and must ensure the map is updated. The most common cause of a sudden, site-wide degradation in localization is not a software fault but an unannounced physical change, such as a new rack row installed over a weekend, a conveyor moved, or a wall of temporary storage built for peak season, that nobody told the map about. Calibration and sensor health Sensors degrade quietly. A depth camera's lens accumulates dust, especially near dock doors and in facilities that handle cardboard in volume, and its depth becomes noisier and its range shorter. A camera mount is bumped during maintenance and its extrinsic calibration shifts by a degree, making the floor appear to slope and low obstacles vanish. A lidar's window is scratched. A wheel's tyre wears, changing its effective diameter and degrading odometry. None of these produces an error message; each produces a slow drift in perception quality that shows up first as a small rise in interventions in some places. Robust fleets monitor sensor health continuously. They check that the fitted floor plane from each depth camera lies where the extrinsic calibration says it should, flagging a camera whose apparent floor has tilted. They track the fraction of valid depth pixels and the noise on known flat surfaces, flagging a camera whose image is degrading. They compare odometry with scan-matched motion, flagging a robot whose wheels are slipping or whose tyres have worn. They schedule recalibration and lens cleaning as routine maintenance rather than as a response to failure. This is unglamorous work, and it is a large part of what separates fleets that improve over time from fleets that slowly decline. Anatomy of an investigation It helps to follow one failure through this machinery, because the steps show how the pieces of a perception system have to be examined together. The scenario below is a composite rather than a report of any particular site, but each element of it is of a kind that recurs. A fleet's intervention rate, steady for weeks, begins to rise. The breakdown by location shows the increase concentrated in one cross-aisle near the outbound docks, and the breakdown by time shows it concentrated between about two and four in the afternoon. The interventions are of two kinds: robots stopping in the cross-aisle for no visible reason and waiting until an operator nudges them on, and, less often, robots reporting low localization confidence as they leave it. The triggered recordings from the stops are replayed. The local costmap at the moment of each stop shows a band of occupied cells across the robot's path a metre or two ahead, where the camera footage shows bare floor. The raw depth images show where the band comes from: a patch of the floor, lit by sun through a high window, is returning depth values well above floor level. The forward camera's active stereo is matching the bright, nearly textureless patch poorly, and the mismatches are being reported as surfaces a few tens of centimetres high. The obstacle layer, faithfully applying its inverse sensor model, marks them as obstacles; the robot, faithfully applying its planner, stops. The localization drops have a related but different cause. The same sunlight saturates part of the planar lidar's view of a glossy wall panel, producing spurious short readings, and the particle filter's likelihood field model, scoring those readings against the map, finds the scan a poor fit everywhere and spreads its particles. Neither failure is a bug in any one component. The depth camera is behaving according to its physics, the costmap according to its design, the planner according to its rules. The fix has several parts, and they span the system. The perception filter is tightened to reject depth points from regions of very low stereo confidence, which the camera reports per pixel. The obstacle layer is configured to require a candidate obstacle to persist across several frames and to be seen by more than one sensor before it blocks the path in that zone. The likelihood field model's random-reading component is raised slightly, making it more tolerant of spurious returns. And the site, asked whether anything had changed, confirms that a set of blinds on the high windows was removed during a maintenance project two weeks earlier; they are reinstated. The recordings join the regression suite, so that the next software release is tested against an afternoon of sunlight it would otherwise never have seen. The lesson is general. Failures in deployed perception rarely belong to a single component, and a team that owns only one component, the detector or the SLAM system, will tend to see only the part of the failure that falls within it. Effective investigation requires people and tools that can follow the evidence from the photons to the motor commands. The long tail The last and most persistent challenge is the long tail of rare situations. Each one is uncommon. Collectively, across a fleet driving thousands of kilometres a week, they are certain. Some examples, drawn from the kinds of problems that recur in warehouse deployments, give the flavour. A new supplier ships product on pallets of a colour or design the detector has never seen, and recall drops. A retrofit replaces the facility's lighting, changing the appearance of every surface the visual SLAM system recognised. A floor is resurfaced with a glossier finish, and time-of-flight depth begins showing reflections of the racking below the floor. Workers start wearing a new style of high-visibility vest whose retroreflective strips saturate the depth sensor at close range. A seasonal promotion fills the cross-aisles with stacked display units. Low winter sun reaches through a dock door for an hour each afternoon that it never reached in summer. A shrink-wrap machine is relocated and its trailing film catches in a robot's caster. There is no general solution to the long tail. There is only a process: detect each failure when it occurs, record it, understand its cause, fix it, add it to the regression suite, and look for others like it. The perception architecture described in this book makes that process tractable. Because uncertainty is represented explicitly, failures announce themselves as drops in confidence rather than as silent errors. Because static, semi-static and dynamic content are separated, a change in what is on the floor rarely corrupts the map the robot localises against. Because detection and geometry are fused, the robot can recognise when the two disagree, which is often the first sign of something new. And because the navigation channel and the safety channel are separate, a perception failure in the long tail is far more likely to cost a minute of productivity than to cause harm. A fleet that works is not one in which perception never fails. It is one in which perception fails gracefully, visibly, and less often each month. Conclusion Return to the aisle at two in the morning. The robot coming down it is doing, every few milliseconds, something remarkable. Its depth cameras are measuring the geometry ahead, with errors it can anticipate from their physics. Its detector is sorting what it sees into people, vehicles, pallets and structure. Its localization is comparing the shape of the racking with a map and maintaining a belief, with an honest account of its uncertainty, about where it is. Its occupancy grid is accumulating evidence about which patches of floor are free, clearing what has gone and marking what has arrived. Its planner is choosing a path that keeps a margin from the racks, passes behind the picker rather than in front, and stays out of the forklift's lane. And underneath all of it, a certified safety scanner watches a protective field, ready to stop the machine if everything else has failed. None of these components, alone, is the reason the robot works. The reason is the way they are put together, and the principle that governs how they are put together is the one this book began with: a robot does not see the world; it estimates it. Several conclusions follow from taking that principle seriously, and they are worth drawing out, because they change how one should build, buy or evaluate a warehouse robot. What follows The first is that uncertainty is a feature to be engineered, not a defect to be minimised. The temptation in perception engineering is to chase accuracy: a more precise depth camera, a detector with higher benchmark scores, a SLAM system with lower trajectory error. These help. But a robot's behaviour in the field depends less on how accurate its estimates are than on whether it knows how accurate they are. A robot with modest sensors and well-calibrated uncertainty will slow down in the long featureless aisle, distrust the depth reading off the shrink-wrap, and decline to close a loop it is not sure of. A robot with excellent sensors and overconfident estimation will do none of these, and will fail in ways that are much harder to diagnose. When evaluating a perception system, the most useful question is not "how accurate is it?" but "what does it do when it is wrong, and does it know?" The second is that the decisive distinction in a dynamic warehouse is between what persists and what passes. Classical SLAM and occupancy mapping were built for a static world, and most of their failure modes in warehouses come from treating semi-static content, pallets, carts, rack contents, as if it were structure. The fix is not a better generic algorithm but a perception architecture that classifies content by permanence, localises against the permanent, plans around the present, and forgets the departed. That classification depends on recognising what things are, which is why object detection and SLAM, historically separate fields with separate conferences and separate benchmarks, have to be designed together in this setting. A detector that does not feed the map, and a map that does not use the detector, leave the most important information on the table. The third is that environment and robot are a single system. The cheapest way to solve a perception problem is often not in software at all. A few fiducial markers in the most aliased aisle, a blind over the skylight that floods a staging area with afternoon sun, a rule that staged pallets go in marked bays rather than anywhere in the cross-aisle, a habit of telling the map owner before moving a rack: each of these can eliminate a class of failure that would take months to engineer around. Natural-feature navigation is valuable because it avoids heavy infrastructure, not because any infrastructure is a defeat. The most successful deployments are those where the site's operators and the robot's engineers treat the building's layout, lighting and procedures as part of the perception system. The fourth is that reliability is a process, not a property. No perception stack, however well designed, ships without long-tail failures. What distinguishes a fleet that improves from one that declines is the machinery around the stack: system-level metrics broken down by place and time, triggered recording, a growing regression suite, sensor-health monitoring, managed maps with clear ownership. These are not afterthoughts to be added once the algorithms work. They are what makes the algorithms keep working. What remains unsettled Several important questions are open, and anyone working in this field over the next few years will see them move. The most consequential is whether learned perception can be made safety-rated. Today, the separation between a sophisticated but uncertified navigation channel and a simple but certified safety channel is a sound and necessary design. It is also wasteful: the robot's best understanding of the world, its knowledge that the shape ahead is a person rather than a box, cannot directly govern its safety behaviour. Work on certifying neural network perception, on runtime monitors that detect when a network is operating outside its competence, and on safety-rated three-dimensional sensors is progressing, and as it matures the boundary between the two channels will move. How fast, and with what assurance, is not yet clear. A second is how far large pretrained models will reshape the field. Open-vocabulary detectors and promptable segmentation have already changed how training data is produced. Vision-language models that can answer questions about a scene, and large models trained on robot data across many embodiments, promise robots that recognise unfamiliar objects and understand instructions such as "avoid the area where the spill is being cleaned." Whether these capabilities can be delivered at the latency, power and reliability a warehouse robot requires, and integrated with the geometric machinery that still does the real work of localization and mapping, is an active question rather than a settled one. A third is the representation of the map itself. The occupancy grid has served for four decades and will not disappear soon, but the direction of research, towards semantic layers, scene graphs and maps that model objects with histories, suggests that the robot's model of a warehouse will increasingly resemble a database of things rather than a picture of space. That shift would make robots far more useful as sources of information about the building, and far more dependent on the quality of their recognition. What to do differently For an engineer building perception for warehouse robots, the practical upshot is to design for the building rather than the benchmark: test on data from the deployment, model sensor errors honestly, separate content by permanence from the start, and invest early in logging, replay and regression testing. For someone evaluating or buying robots, it is to ask the questions that reveal how a system behaves when the world does not cooperate. How does the robot localise in your longest, most uniform aisle, and what happens to its confidence there? How does its map handle pallets that are moved daily? What does it do with black stretch wrap, clear film, and sunlight through your dock doors? How are map changes made, distributed and owned? What are the fleet's interventions per hour at comparable sites, and how has that number changed over the first six months of each deployment? A vendor with good answers to these questions has understood the problem. A vendor who answers only with benchmark scores and demonstration videos has not yet met your building. For everyone, it is to see the robot coming down the aisle not as a machine that sees, but as a machine that estimates, doubts, revises and forgets, and to judge it by how well it does those things in the place where it actually has to work. Further Reading Foundational books Sebastian Thrun, Wolfram Burgard and Dieter Fox, Probabilistic Robotics (MIT Press, 2005). The standard text on the probabilistic view of robot perception. Its chapters on Bayes filters, Monte Carlo localization, occupancy grid mapping and SLAM remain the clearest treatment of the ideas behind Chapters 1, 4, 5 and 6 of this book. Timothy D. Barfoot, State Estimation for Robotics (Cambridge University Press, 2017). A rigorous, modern account of estimation, with careful treatment of three-dimensional rotations and batch optimisation. Demanding but rewarding. Frank Dellaert and Michael Kaess, "Factor Graphs for Robot Perception," Foundations and Trends in Robotics 6, nos. 1–2 (2017). A compact introduction to the factor-graph formulation that underlies modern SLAM back ends, by two of its principal developers. Richard Hartley and Andrew Zisserman, Multiple View Geometry in Computer Vision, 2nd ed. (Cambridge University Press, 2004). The reference work on camera models, stereo, and the geometry of reconstruction from images. Richard Szeliski, Computer Vision: Algorithms and Applications, 2nd ed. (Springer, 2022). A broad and current survey of computer vision, including depth estimation, feature matching and recognition. The author makes a version freely available online. Roland Siegwart, Illah Nourbakhsh and Davide Scaramuzza, Introduction to Autonomous Mobile Robots, 2nd ed. (MIT Press, 2011). An accessible overview of mobile robot locomotion, sensing, localization and planning. Surveys Cesar Cadena and colleagues, "Past, Present, and Future of Simultaneous Localization and Mapping: Toward the Robust-Perception Age," IEEE Transactions on Robotics 32, no. 6 (2016). The most widely cited survey of SLAM, with a frank discussion of open problems including dynamic environments and long-term operation. Hugh Durrant-Whyte and Tim Bailey, "Simultaneous Localization and Mapping: Part I," IEEE Robotics and Automation Magazine 13, no. 2 (2006), with Part II by Bailey and Durrant-Whyte in the following issue. A clear tutorial on the structure of the SLAM problem and its classical solutions. Steve Macenski and colleagues, "From the Desks of ROS Maintainers: A Survey of Modern and Capable Mobile Robotics Algorithms in the Robot Operating System 2," Robotics and Autonomous Systems 168 (2023). A practitioner's survey of the localization, mapping, planning and control algorithms available in ROS 2. Sensing and detection Leonid Keselman and colleagues, "Intel RealSense Stereoscopic Depth Cameras," Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition Workshops (2017). A technical description of the active stereo design behind the RealSense D400 family. Shaoqing Ren, Kaiming He, Ross Girshick and Jian Sun, "Faster R-CNN: Towards Real-Time Object Detection with Region Proposal Networks," Advances in Neural Information Processing Systems (2015). The definitive two-stage detector. Joseph Redmon, Santosh Divvala, Ross Girshick and Ali Farhadi, "You Only Look Once: Unified, Real-Time Object Detection," Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (2016). The paper that began the single-stage real-time lineage. Nicolas Carion and colleagues, "End-to-End Object Detection with Transformers," European Conference on Computer Vision (2020). The DETR paper, which recast detection as set prediction. Tsung-Yi Lin and colleagues, "Microsoft COCO: Common Objects in Context," European Conference on Computer Vision (2014). The benchmark that defined modern detection evaluation. Alex Bewley, Zongyuan Ge, Lionel Ott, Fabio Ramos and Ben Upcroft, "Simple Online and Realtime Tracking," IEEE International Conference on Image Processing (2016). The SORT tracker, a compact and influential baseline for multi-object tracking. Localization, SLAM and mapping Alberto Elfes, "Using Occupancy Grids for Mobile Robot Perception and Navigation," Computer 22, no. 6 (1989). The classic statement of the occupancy grid. Frank Dellaert, Dieter Fox, Wolfram Burgard and Sebastian Thrun, "Monte Carlo Localization for Mobile Robots," Proceedings of the IEEE International Conference on Robotics and Automation (1999). The particle-filter localization method behind AMCL. Giorgio Grisetti, Cyrill Stachniss and Wolfram Burgard, "Improved Techniques for Grid Mapping with Rao-Blackwellized Particle Filters," IEEE Transactions on Robotics 23, no. 1 (2007). The GMapping paper. Wolfgang Hess, Damon Kohler, Holger Rapp and Daniel Andor, "Real-Time Loop Closure in 2D LIDAR SLAM," Proceedings of the IEEE International Conference on Robotics and Automation (2016). The Cartographer paper. Steve Macenski and Ivona Jambrecic, "SLAM Toolbox: SLAM for the Dynamic World," Journal of Open Source Software 6, no. 61 (2021). The default two-dimensional SLAM system in ROS 2, designed for large spaces and lifelong mapping. Raúl Mur-Artal, J. M. M. Montiel and Juan D. Tardós, "ORB-SLAM: A Versatile and Accurate Monocular SLAM System," IEEE Transactions on Robotics 31, no. 5 (2015); and Carlos Campos and colleagues, "ORB-SLAM3: An Accurate Open-Source Library for Visual, Visual-Inertial, and Multimap SLAM," IEEE Transactions on Robotics 37, no. 6 (2021). The leading feature-based visual SLAM lineage. Mathieu Labbé and François Michaud, "RTAB-Map as an Open-Source Lidar and Visual SLAM Library for Large-Scale and Long-Term Online Operation," Journal of Field Robotics 36, no. 2 (2019). A versatile RGB-D and lidar SLAM system widely used with depth cameras. Jürgen Sturm and colleagues, "A Benchmark for the Evaluation of RGB-D SLAM Systems," Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (2012). The TUM RGB-D benchmark and its trajectory error metrics. Armin Hornung, Kai M. Wurm, Maren Bennewitz, Cyrill Stachniss and Wolfram Burgard, "OctoMap: An Efficient Probabilistic 3D Mapping Framework Based on Octrees," Autonomous Robots 34, no. 3 (2013). The standard three-dimensional occupancy representation. Richard A. Newcombe and colleagues, "KinectFusion: Real-Time Dense Surface Mapping and Tracking," IEEE International Symposium on Mixed and Augmented Reality (2011); and Helen Oleynikova and colleagues, "Voxblox: Incremental 3D Euclidean Signed Distance Fields for On-Board MAV Planning," Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (2017). The foundations of dense volumetric mapping for planning. Dynamic environments and long-term operation Berta Bescos, José M. Fácil, Javier Civera and José Neira, "DynaSLAM: Tracking, Mapping, and Inpainting in Dynamic Scenes," IEEE Robotics and Automation Letters 3, no. 4 (2018). Semantic masking of dynamic objects in visual SLAM. Peter Biber and Tom Duckett, "Dynamic Maps for Long-Term Operation of Mobile Service Robots," Robotics: Science and Systems (2005). Maps at multiple timescales. Tomáš Krajník and colleagues, "FreMEn: Frequency Map Enhancement for Long-Term Mobile Robot Autonomy in Changing Environments," IEEE Transactions on Robotics 33, no. 4 (2017). Modelling periodic change in maps. Nathan Hughes, Yun Chang and Luca Carlone, "Hydra: A Real-Time Spatial Perception System for 3D Scene Graph Construction and Optimization," Robotics: Science and Systems (2022). Hierarchical semantic maps. Navigation and safety Dieter Fox, Wolfram Burgard and Sebastian Thrun, "The Dynamic Window Approach to Collision Avoidance," IEEE Robotics and Automation Magazine 4, no. 1 (1997). The template for sampling-based local planning. Steve Macenski, Francisco Martín, Ruffin White and Jonatan Ginés Clavero, "The Marathon 2: A Navigation System," Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (2020). The design of Nav2, the ROS 2 navigation stack. Christoph Schöller, Vincent Aravantinos, Florian Lay and Alois Knoll, "What the Constant Velocity Model Can Teach Us About Pedestrian Motion Prediction," IEEE Robotics and Automation Letters 5, no. 2 (2020). A sobering baseline for human motion prediction. ISO 3691-4:2023, Industrial trucks — Safety requirements and verification — Part 4: Driverless industrial trucks and their systems; and ANSI/A3 R15.08-1-2020 and R15.08-2-2023, Industrial Mobile Robots — Safety Requirements. The governing safety standards for autonomous vehicles and mobile robots in industrial spaces. Hashtags: #ComputerVisionForRobotics #ComputerVision #Robotics #ObjectDetection #SLAM #SimultaneousLocalizationAndMapping #RobotPerception #AutonomousRobots #MobileRobotics #AutonomousMobileRobots #AMR #WarehouseRobotics #WarehouseAutomation #RoboticNavigation #RobotLocalization #RobotMapping #VisualSLAM #RGBDSLAM #LaserSLAM #DynamicSLAM #SemanticSLAM #ProbabilisticRobotics #BayesianEstimation #SensorFusion #DepthCameras #DepthSensing #RGBDCameras #StructuredLight #TimeOfFlight #ActiveStereo #StereoVision #LiDAR #PointCloudProcessing #ThreeDimensionalPerception #DeepLearning #MachineLearning #YOLO #FasterRCNN #DETR #ObjectRecognition #InstanceSegmentation #ObjectTracking #MultiObjectTracking #KalmanFilter #ExtendedKalmanFilter #ParticleFilter #MonteCarloLocalization #AMCL #RobotOdometry #LoopClosure #PoseGraphOptimization #FactorGraphs #OccupancyGridMapping #OccupancyGrids #LogOddsMapping #DynamicObjectDetection #SemanticMapping #SensorCalibration #VisualPlaceRecognition #PathPlanning #ObstacleAvoidance #CollisionAvoidance #HumanAwareNavigation #CostmapNavigation #AutonomousNavigation #ROS2 #Nav2 #RobotOperatingSystem #RoboticsSimulation #RobotSafety #RealTimeObjectDetection #EmbeddedAI #RoboticsEngineering