Preface: On the Name

This book’s central concept acquired its name twice. In early drafts it was the “Logical Assembly” — two words, descriptive, and a little gray. Midway through the work we collapsed it into one word, LogicalAssembly, and gave it the abbreviation Lasm, pronounced the way it looks. The gesture was an homage: the model is WebAssembly, abbreviated Wasm, the compact binary format that since 2017 has served as the web’s fourth language and, increasingly, as a universal compilation target far beyond the web. We renamed our concept to honor a piece of infrastructure we admire. Only afterward did we notice that the homage was not decorative. The name we had borrowed contained, in compressed form, the entire argument of this book. A preface conventionally explains how a book came to be written; this one explains how it came to be named, because in our case the two stories turn out to be the same story.

WebAssembly is not a programming language in the ordinary sense; almost no one writes it by hand. It is a target: C, C++, Rust, Go, and dozens of other languages compile into it, and browsers, servers, and edge runtimes execute it. It was designed by consortium and specified with unusual formality — its semantics were given mathematical rigor from the start — and it now runs, identically, on billions of machines whose owners have never heard of it. It has been observed, accurately, that WebAssembly is neither web nor assembly. The quip is true and misses what matters. The name gestures backward at assembly language, the oldest human-legible stratum of computation, while the artifact itself occupies a position no assembly language ever held: a stable intermediate form between two zones of extreme volatility — programming languages above it, execution environments below.

Ask why WebAssembly can be trusted to persist, and the answer is not elegance, though the specification is elegant. It is enforcement. Every engine that executes a module is a checking machine: the module either validates against the specification or it does not run. Divergence between the specification and reality is not a quiet documentation problem discovered years later in an audit; it is an immediate, visible, attributable failure, surfaced millions of times a second by every host in the world. The specification cannot rot, because the world breaks against it daily and at scale. Its position matters as much as its policing. Network engineers call this shape the narrow waist — the Internet Protocol is the canonical case — a thin, stable layer through which everything above must pass to reach everything below. The narrow waist outlives the churn on both sides of it, not because it is protected but because it is used, universally, by things that fail without it.

Each of these properties is one the LogicalAssembly aspires to, transposed from the domain of computation to the domain of organizational meaning. A Lasm is a target, not a source: it is what an organization’s knowledge — its schemas, code, policies, and practice — compiles into, rather than a document anyone sits down to write. It is runtime-independent: no particular application, vendor, or foundation model appears anywhere in it, which is why it is designed to survive the replacement of all of them. It is enforced: evaluation suites gate whether agents may act, the way validation gates whether modules may run. And it is a narrow waist: many sources of meaning compile in; many consumers — agents, applications, reports, integrations — project out; the stable thing in the middle stays small because volatility has been pushed to the edges. What WebAssembly is to computation, the LogicalAssembly proposes to be for meaning.

“Assembly” is among the oldest words in software: when David Wheeler wrote the initial orders for the EDSAC at Cambridge in 1949, the point was to make raw machine operation composable by a human being — the first translation stratum between meaning and mechanism, and the ancestor of every compiler since. But the word never surrendered its other senses. An assembly of parts is a whole held together by function rather than essence — remove a component and something specific stops working. An assembly of people is a deliberative body — a forum whose records are the durable trace of what a community has decided. A LogicalAssembly is all three at once: a translation stratum between organizational meaning and machine action; a functional composition of heterogeneous parts; and, in its governance, something like a deliberative record of what an organization has resolved its world to mean.

“Logical” has its own quiet lineage, and it is closer to this book’s subject than the philosophical one. In 1975 the ANSI/SPARC committee on database management gave the field its three-schema architecture, separating the logical description of data from the physics of its storage — precisely so that disks, indexes, and layouts could be reorganized without destroying the meaning above them. They called the property data independence, and it quietly became one of the most successful abstractions in the history of computing. The database community, in other words, solved a local version of this book’s problem fifty years ago, and the layer they designed to survive change is the one they named logical.

We initially chose the name as an homage but only understood it trully in hindsight. That order of operations — gesture first, comprehension after — may strike some readers as backward, but we report it honestly, because the discovery hiding inside the name is the book’s thesis. Durability, in representations, is not a property of content; it is a function of enforcement. A representation endures when divergence from it fails visibly. WebAssembly does not persist because it is well made, though it is. It persists because code that diverges from it fails, immediately and observably, everywhere it runs. This book asks what it would take for an organization’s understanding of itself — its concepts, constraints, events, policies, and criteria of success — to persist the same way.

A closing word on genre. This is an essay in the older sense — an attempt, a weighing — not a standard, a schema, or an implementation guide. It proposes definitions, a causal account of why some representations survive their authors and most do not, and tests by which the whole proposal could be found wrong. Parts I and II build the argument from its inheritances in philosophy, information theory, and physics. Part III turns to construction. Part IV states the failure modes as carefully as the claims. Readers impatient for machinery may start at Chapter 7 and work backward as the definitions send them there; skeptics are invited to begin at Chapter 10, which was written for them.