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. Before examining its models and alignment mechanisms, a few facts about the system are enough.

1.2.1 Accessibility and the Engineering Experiment

The explicit problem is the scale of inaccessible documents. In 2024 the Department of Justice gave public universities a deadline: the slide decks, PDFs, and spreadsheets they distribute must meet a real accessibility standard, so that a student using a screen reader gets the same course as everyone else. A typical deck fails that standard dozens of ways — images with no descriptions, missing titles, a reading order no machine can follow. Our estimate for remediating one course's materials by hand was roughly 7.5 full work weeks, and a university offers thousands of courses. The requirement is clear; the arithmetic is crushing. The ADA Context walks the full bind.

The implicit problem was mine. In early 2026 coding agents got good enough that I, a professor of software engineering, no longer knew what my discipline's daily craft was about to become — and the only way to find out was to build something real with them and watch what the work demanded. Accessibility remediation therefore served both purposes: build a consequential production system, and use the engineering work to discover what sustained agentic development actually demanded. The system became DocAble; the resulting method became MAGE. Part V returns to how that method emerged from the build.

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.

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 — the kind of production system these ideas govern. image — no alt text not accessible ! an inaccessible document unlabeled images · untagged · no reading order DocAble the production system scholaccess.com what it does — not yet how upload remediated file image — described ✓ evidence record an accessible document + evidence tagged · reading order · every fix explained Here is the kind of production system these ideas govern — what it does, not yet how.
Figure 1.2-1. DocAble from the user's view. An inaccessible document goes in; a remediated document and evidence of the consequential changes come back. Internal structure is omitted because it is not yet relevant.

The 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 The Territory

Before Parts II and III represent DocAble through different engineering models, we need enough common territory to know what those models refer to. Figure 1.2-2 follows one ordinary job through the system.

One DocAble job, as territory rather than model A submitted document becomes a job. The job 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 and the evidence describing consequential changes. This is territory, not a model of DocAble's architecture. ONE DOCABLE JOB territory, not model user uploads document 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. One DocAble job—the territory later models describe. A document becomes a job, may be divided into chunks, is processed by workers using specialized services, then reassembled, validated, and returned with evidence. Parts II and III will represent selected pieces of this territory differently depending on the engineering question.

A job is one document's trip through the system. A chunk is a portion of that job 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 its engineering can be shown 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 selected engineering obligations acquire authority over the work.

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 productive substrate that makes autonomous implementation possible.

© James C. Davis, 2026–present