Chapter 2. Analysis and Synthesis

Chapter 1 defined a web application but left State untyped. Looking at existing applications does not determine a model: one uses rows, another trees, another object graphs. That variety is what Proposition 1.3 predicts: any architecture fits Definition 1.1, so every kind got built. Choosing a preferred model would be equally arbitrary. Instead, this book derives requirements for State from constraints imposed by the web itself. If the derivation is valid, rejecting the resulting model requires rejecting at least one of those constraints.

State itself is not directly observable. Requests and responses are visible on the wire, and the document returned by read is public, but the server’s internal state is not. The analysis therefore starts from the document and works inward. It removes properties that can vary without changing the underlying information, checking each removal against ordinary web behavior. The layers that can be removed become the factors of read; what survives every removal is the first direct evidence of what State must contain.

Stripping a document can suggest such a factorization, but it does not by itself prove that the factorization is necessary. The result could still depend on the particular pages chosen or on the order of the removals, rather than apply to every page. The check is independence: set the pages aside, keep only the derived parts, and build with them. A working application space means the full range of applications Definition 1.1 admits, not one rebuilt demo. If that space can be constructed from the derived parts alone, using nothing from the original pages, then the skeleton was in the pages, not in the procedure. And if the construction fails, or quietly needs parts the derivation never produced, the failure is public: either the analysis kept the wrong things or the parts list is incomplete, and each defect is visible on its own.

The Greek geometers called the two directions analysis and synthesis. Pappus’s Collection describes the pair: assume the thing sought and work backwards to what is established; then reverse the path, and the reversal is the proof. Newton restates it as a rule of natural philosophy in the Opticks: the investigation of difficult things by analysis “ought ever to precede the method of composition.” The practice has modern instances wherever a structure must be known rather than guessed. Organic chemists worked out a molecule’s structure by breaking it into identifiable fragments, and accepted that structure as proven only once they had built the same compound from known ingredients and it matched. Software has the clean-room: a rebuild is independent exactly when the rebuilding team touched only the derived specification, never the original. Both keep the geometers’ point: taking apart suggests a structure; only building back, independently, proves it.

The claim can now be stated precisely. The analysis, if it succeeds, will show necessity: every web application has the derived form, because under Definition 1.1 there is nothing else read and State could be. The synthesis, if it succeeds, will show sufficiency: the derived parts are enough to build the full application space, with nothing missing. Neither half proves the claim alone; the proof is that the two match, and the book checks the match twice, in theorems and in running code. Where analysis and synthesis do not coincide, Chapter 9 lists the mismatches explicitly. The opening pages already name the result, but naming it proves nothing. The proof is the derivation, and that is the part a reader can check.

The book follows the same method. Part II performs the analysis first on real pages and then as theorems that quantify over arbitrary pages. Once the properties of State are derived, the write side follows. Part V reconstructs an application space from the derived components. Between analysis and synthesis, Parts III and IV compare the result with existing standards and current technologies and record the mismatches. Part VI considers what follows from the resulting architecture.

The method used in the book. Analysis (Part II) works from the observable Doc toward State and establishes necessity. Synthesis (Part V) builds from State back to documents and establishes sufficiency. Chapter 8 compares the two formally, Chapter 19 does so in running code, and Chapter 9 records the mismatches.

One decision remains before the stripping starts, and it is a control on the experiment: which pages to strip. At least two are needed, because one page says nothing about pages in general. The most useful pair is two very different pages: anything that survives the same removals in both is less likely to be specific to either one. So the pair is a newspaper front page and a wind-farm dashboard. The front page is written by a handful of editors on an editorial rhythm and read by millions. The dashboard is written continuously by machines and read by one operator on shift. Different domain, different audience, opposite rhythms of read and write; under Definition 1.1 they have one signature. If these two reduce to the same skeleton, everything between them likely does too. Print both. Now take them apart.