§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. 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 three times larger (1,501,907 lines, a 3.0× support-to-production ratio). 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 states the eight requirements that system had to satisfy.
| Requirement | DocAble must… |
|---|---|
| R1 · Multi-format remediation | Remediate educational documents in the formats people actually use, including Office (PowerPoint, Word, Excel) and PDF. |
| R2 · Semantic remediation | Perform semantic repairs that require understanding document content, not only syntactic, deterministic transformations. |
| R3 · Preserve the document | Retain content, appearance, and behavior except where remediation requires a change. |
| R4 · Standards-grounded accessibility | Evaluate and repair documents against their governing obligations (WCAG 2.1 AA), not proxy checker scores. |
| R5 · Evidence | Record what accessibility requirement motivated each change and what evidence supports the resulting document state. |
| R6 · Reviewability | Make outputs auditably traceable: consequential automated changes are inspectable and, where appropriate, reversible. |
| R7 · Production operation | Process real documents at practical sizes, costs, and latency. |
| R8 · Institutional deployment | Operate as a deployed service that scales to thousands of faculty at one institution, and preferably nationwide. |
These requirements are enough to understand the examples that follow. Chapter 5 returns to them as engineering constraints and examines what happened when I tried to satisfy them while delegating most implementation to coding agents.
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.
That is the modeling move Chapter 2 develops.
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 puts those mechanisms in motion. 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 provides depth, not the book's entire evidentiary basis. Other engineering organizations reappear throughout the book to show where related structures recur, where they take different forms, and where the evidence supports a more limited interpretation.
We can now examine the machinery that makes autonomous implementation possible and the engineering mechanisms through which MAGE acts on it.