A single chart has one question and one answer. A project has several related questions, a shared visual language, a publication context, and a paper trail of decisions that lets someone else , or future you , understand why each choice was made. The difference is not scale. A project with three charts is still a project. The difference is that a project makes the relationship between the charts explicit.

The MBTA team began with three questions. This is not a workflow choice. It is the only sequence that produces a coherent project. If you start with the data, you will produce charts that show whatever the data makes easy to show. The chart will be technically accurate and communicatively inert , a mirror of the data's structure, not an answer to a question anyone has. The reader will look at it and not know what to do with it.

Phase B builds the infrastructure the project needs before any chart is generated. Three files: CLAUDE.md, DESIGN.md, and PROJECT.md. This split was introduced in Chapter 00 and matters more in a project than in a single-chart session. The reason is the instruction budget: Claude Code's context window can hold only so many constraints reliably.

With the three questions framed and the schema files written, Phase C produces the charts. One chart at a time. Each chart prompt follows the four-move structure. Each chart gets the channel decomposition that the question demands. Question 1 asks about both ranking (which countries) and change over time (how has this changed). A heatmap answers both simultaneously: countries on the y-axis, years on the x-axis, color luminance encoding the count.

Every chart goes through the Evergreen/Emery 22-point checklist before it is called publishable. Chapter 15 walks the full checklist. For the three charts in this project, the checklist is applied in order, and every failure gets a targeted follow-up prompt. The audit is not a formality. It is the mechanism that finds the things the prompt specification missed. The label that is too small at deployment width. The color that looks fine on a calibrated monitor but fails the color-blind simulation.

A publishable chart is not a published chart. The handoff includes everything the reader needs to trust the chart and know where the data came from. Source citation: "Data: UNHCR Refugee Statistics, 2024. Available at: unhcr.org/refugee-statistics." The reader must be able to verify the data. Methodology note: "Counts are point-in-time totals as of December 31 of each year. Some counts include UNHCR estimates where national data is unavailable." The reader must know the data's limitations. Data quality note: "Data quality varies by country.

The book has invoked Cairo's ethical frame throughout. This chapter is where it applies most directly to a completed project. Cairo's criterion: the purpose of the graphic is to answer the question. A chart that is technically clean, perceptually accurate, well-annotated, and visually polished , but which does not answer the communication question it was supposed to answer , is a failed chart. The audit catches technical and perceptual failures. This test catches purpose failures.

The book's argument has been that D3 visualization was two problems. The first: implementation. Writing valid D3 code for a specific chart type on a specific dataset took hours; the barrier was technical. The second: design. Knowing what chart to build, which channel to use for which attribute, how to apply the relevant design rules, how to audit the output , these require judgment that cannot be automated. Claude Code dissolved the first problem. A chart that took a day to implement now takes twelve seconds.

Exercise 17.1 , Frame three questions. Take a dataset you work with or have access to. Write three reader-focused communication questions following the MBTA model. Each question should name the audience, the specific thing they need to know, and the decision the answer informs. Test each question: can it be answered by a single chart or small set of charts? If not, narrow it. Exercise 17.2 , Build CLAUDE.md. Draft a CLAUDE.md for a project in your domain.

MBTA process model. Question goes to data audit goes to prototype goes to select goes to build goes to audit goes to publish. Start with the question; let the data and the iteration reveal the chart. CLAUDE.md. The project's coding constitution. D3 version, encoding requirements, naming conventions, accessibility defaults. Loads every session. Short enough that Claude Code retains it reliably.

The ideas in this chapter didn't appear from nowhere. Buckminster Fuller spent decades insisting that a designer's job is not to make objects but to make the whole system legible to the people who have to live with it. His Dymaxion map and the World Game were enormous communication projects: a data narrative wrapped around a verifiable artifact, end to end. The complete-project discipline of this chapter , README to chart to audit log , is Fuller's idea of legibility scaled down. Buckminster Fuller, circa 1962.

The ideas in this chapter didn't appear from nowhere. Buckminster Fuller spent decades insisting that a designer's job is not to make objects but to make the whole system legible to the people who have to live with it. His Dymaxion map and the World Game were enormous communication projects: a data narrative wrapped around a verifiable artifact, end to end. The complete-project discipline of this chapter , README to chart to audit log , is Fuller's idea of legibility scaled down. Buckminster Fuller, circa 1962.