§1.2 MAGE by Example: Summary of the DocAble Case
DocAble provides the book's deepest worked example: a production accessibility system built largely through coding agents. Chapter 5 presents the full case study; before examining its models and Alignment mechanisms here, a few facts about the system are in order.
1.2.1 Accessibility and the Engineering Experiment
In 2024, the U.S. Department of Justice gave public universities a deadline to make their digital content accessible, measured against the Web Content Accessibility Guidelines (WCAG 2.1 Level AA). A typical slide deck can fail the standard in dozens of ways: images without descriptions, missing titles, or a reading order that a screen reader cannot follow. I estimated that remediating one course's materials by hand would require roughly 8 full work weeks; a university offers thousands of courses. I personally maintain two courses and had no desire to spend a full semester remediating them manually. I could delegate some of that work to other people, but delegation would not make me any less responsible for the result. I was, however, perfectly willing to spend six months attempting to automate the work to my own standard.
In early 2026, coding agents had also become capable enough to make a different experiment possible. I wanted to know what software engineering would look like if I stopped writing most of the implementation myself, so I used accessibility remediation as a real production problem on which to find out. The system became DocAble; the resulting method became MAGE. MAGE makes the judgment of one engineer capable of governing the implementation capacity of a software team. Chapter 5 returns to the build and examines how that capability emerged.
1.2.2 What the User Sees
From the user's perspective, DocAble is simple: upload an inaccessible document; receive a remediated document and an evidence record. It works across common document formats: Word, PowerPoint, and Excel; their LibreOffice equivalents; PDF; and text-based formats including LaTeX and Typst. Figures are described, reading order is repaired, and structural accessibility is restored where possible.
Why not simply give the entire document to a capable multimodal model and ask it to make the document accessible? I tried that too. For documents within their operating range, capable models can produce impressive results. But the approach is expensive because the model must reconstruct properties already available deterministically in the document (the document's title may be right there on the page, but represented as large bold text rather than Word's Title style); large documents can exceed its practical operating range (the model may simply give up before finishing the deck); and support varies across formats (a model that handles PowerPoint may not accept PDF).
More importantly, "the model said it was accessible" is not an adequate compliance case. To trust that result, we would still have to make explicit the obligations against which it should be judged. The governing obligation is not merely to produce a plausible-looking artifact, but to provide students with a substantially equivalent experience. If a result is challenged, the university needs credible evidence of what the system checked (every image was examined for a usable description), what it changed (this image received this alternative text), what it could establish (the repaired reading order matches the intended sequence), and what limitations remain (this element could not be remediated automatically). DocAble therefore treats accessibility remediation as an engineering problem rather than a single act of inference.
Before looking inside the system, Figure 1.2-1 shows only the engineering result it is supposed to produce.
That simple interface hides a large production system. At the observation point used in this book, DocAble comprised roughly 491,090 lines of production code, governed by a support apparatus about 3.0 times its size (1,501,907 lines). The examples that follow isolate individual engineering questions from that system. Together they show different places where Modeling and Alignment enter the work.
Table 1.2-1 groups what that system had to accomplish into four kinds of obligation.
| Kind of obligation | DocAble must… |
|---|---|
| Genuine accessibility | Repair problems that require understanding document content, judged against the governing standard (WCAG 2.1 AA) rather than proxy checker scores. |
| Preservation | Retain the document's content, appearance, and behavior except where remediation requires a change. |
| Accountability | Record what motivated each change and what evidence supports the result, keeping consequential changes inspectable and, where appropriate, reversible. |
| Practical operation at scale | Handle the formats people actually use, at practical sizes, costs, and latency, as a deployed service for thousands of faculty. |
Two tensions among these obligations make DocAble an engineering problem rather than a file-conversion task. Accessibility can conflict with preservation: repairing a reading order or describing a figure means changing the document, and the change must not damage the author's content, appearance, or editability. And semantic quality pulls against economical automation: some repairs need the contextual interpretation foundation models supply, but model output is uncertain and can be expensive, so the system must combine that inference with deterministic processing and validation.
These examples establish the nature of the engineering problem. Chapter 5 presents the complete requirements and examines how they shaped the resulting system.
1.2.3 One System, Several Engineering Questions
Building DocAble well is not one engineering problem. Different questions require different representations.
Ask what the system contains and how its parts relate, and you want a structural view. Ask what happens to a document after upload, and you want behavior: the states a job moves through and the transitions that are legal. Ask which component may call another, and you want a model of permitted relationships. Ask whether the system is fast and cheap enough, and you want measurements and their allowable envelopes. Ask whether the evidence returned with a document faithfully describes what happened, and you want provenance.
The system has not changed between these questions. The representation has. There is no single model of DocAble that is best for all of them. Each model is a purposeful reduction that preserves the facts needed for an engineering question and suppresses detail that question does not need.
1.2.4 Following One Job
Before Chapters 2 and 3 examine particular properties of DocAble, Figure 1.2-2 follows one ordinary job through the system.
A job tracks one document's trip through the system. A chunk is a portion of that work that can be processed independently. Workers claim and process chunks, calling specialized services for capabilities such as image description, rendering, conversion, or OCR. Queues and other infrastructure coordinate those handoffs. The final outputs are the remediated document and evidence describing consequential changes and remaining findings.
The same worker will appear differently in later models. It may be a deployable component, an actor in a lifecycle, an owner of a resource, a subject of an access policy, or a source of measurements. These are not competing descriptions. Each preserves different properties of the same system for a different engineering question: structure, behavior, ownership, decisions, measurements, or provenance.
1.2.5 How the Book Uses DocAble
DocAble is the book's deepest worked example because the system can be examined at the resolution the method requires. Chapters 2 and 3 use the working system to ask two different kinds of questions. Chapter 2 asks which representations make important system properties tractable. Chapter 3 asks how engineering intent comes to bind the work.
Chapter 4 examines how those mechanisms are used during development. It follows engineering problems through successive models, decisions, implementation, and governance conversion, showing how Modeling and Alignment change as the system changes. Chapter 5 then examines the production system itself: what failed, what those failures revealed, and how recurring judgments became models, controls, and other durable engineering structure.
DocAble is the primary case study. Chapter 5 examines practices at other engineering organizations, identifying where related structures recur, where they take different forms, and where the available evidence supports more limited conclusions.
We can now examine the machinery that makes autonomous implementation possible and the engineering mechanisms through which MAGE acts on it.