Part 1 — The New Engineering Problem  ::  Chapter 2

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. Part V 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—at least not manually. I was, however, perfectly willing to spend a full semester attempting to automate the work.

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. Part V 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, structural accessibility is restored where possible, and consequential changes are recorded so that the result can be inspected and, where necessary, reversed.

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. 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.

A running glimpse of DocAble — one object in, one object back A single input-to-output panel with no internal structure. On the left, an inaccessible document: a page with unlabeled images, no reading order, and no tags, marked not accessible. An arrow labelled the upload leads into DocAble, drawn as one closed box — the production system at scholaccess.com — with a note that this shows what it does, not yet how. An arrow labelled the file, remediated leads out to the right, to an accessible document with described images, reading order, and tags, carrying an evidence record in which every fix is explained. The caption reads: here is the kind of production system these ideas govern — what it does, not yet how. A running glimpse of DocAble One object in, one object back. image — no alt text not accessible ! inaccessible document unlabeled images · untagged · no reading order DocAble the production system scholaccess.com upload remediated file image — described ✓ evidence record accessible document + evidence tagged · reading order · every fix explained
Figure 1.2-1. DocAble from the user's view. An inaccessible document goes in; a remediated document and evidence of consequential changes come back. Internal structure is omitted because it is not yet relevant.

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. They should not be read as the architecture of a small document-processing script.

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 Part II develops.

1.2.4 Following One Job

Before Parts II and III examine particular properties of DocAble, Figure 1.2-2 follows one ordinary job through the system.

Processing one document in DocAble A user submits a document (drawn as a document artifact), which creates a job that tracks its processing. The work splits into chunks so several workers process it concurrently. Workers claim work and call specialized services — generation, render, OCR, and document/format machinery — when remediation needs those capabilities. Repaired pieces are merged and reassembled, the result is validated, and the system returns both the remediated document (again a document artifact) and the evidence describing consequential changes. Document artifacts are drawn with a folded corner; the job, workers, and services are control boxes. ONE DOCABLE JOB user uploads a document creates a job job split for parallel work chunk chunk chunk workers claim work call specialized services generation render OCR document / format machinery repaired pieces merge / reassemble validate remediated document evidence
Figure 1.2-2. Processing one document in DocAble. A user submits a document, creating a job that tracks its processing. The work may be divided into chunks and processed by workers using specialized services for generation, rendering, optical character recognition (OCR), and document-format processing. The resulting changes are reassembled and validated, and the remediated document is returned with evidence.

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. Parts II and III use the working system to ask two different kinds of questions. Part II asks which representations make important system properties tractable. Part III asks how engineering intent comes to bind the work.

The interlude after Part III follows one engineering problem in depth. A large presentation first exposes a memory problem, then a representation problem, then an execution problem. Successive models reveal each one and support design decisions before the corresponding implementation is complete.

Part V uses DocAble differently. It examines the build itself: what failed, what those failures revealed, and how recurring judgments became models, controls, and other durable engineering structure. The earlier Parts show the resulting machinery; Part V shows the engineering experience from which much of it emerged.

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.

© James C. Davis, 2026–present