The Framework · Essay Four

The Second Reader

A health plan denies a claim for physical therapy and emails the member a letter. The letter is accurate. It explains the decision, describes the appeal process, and gives her 180 days to file. She never opens it. In her inbox, under the subject line, her email app shows a summary it wrote on its own: the claim was denied, and she can call member services with questions. The summary leaves out the appeal and the deadline. Nobody at the health plan wrote it, and nobody there will ever see it.

Every institution writes for the person a message is addressed to. That person may now meet the message through a second reader: software that summarizes it, or answers questions about it, before the person reads a word.

What changed

Until recently, a letter reached its reader as written. The reader might skim it or skip it, but the words in front of the reader were the institution’s.

That has changed, in software people use every day. When Apple Intelligence is turned on, Apple’s Mail app places a short summary under each unread email, and Apple’s own guide to the feature says, “Check important information for accuracy.” In January 2026, Google began rolling out summaries of long email threads to every Gmail user in the United States, at no cost. And some people paste a confusing letter into a chatbot and ask what it means.

Apple’s warning puts the burden on the reader. A reader who trusted the summary enough to skip the letter has no way to know what to check.

What a summary keeps

A summary is a set of choices about what to keep. It can keep what a message puts first and lose what the message buries: the deadline in the fourth paragraph, the exception that begins with “unless,” the one sentence that tells the person what to do. What is left still reads as complete.

A summary can also be wrong. In December 2024, Apple’s notification summary of three BBC News alerts opened with a headline the BBC never wrote: “Luigi Mangione shoots himself.” It was false. The BBC complained, saying it is essential that its audiences can trust “any information or journalism published in our name and that includes notifications.” Apple paused summaries for news apps the following month. They came back with iOS 26, along with Apple’s own warning that a summary may change the meaning of the original headline.

The BBC’s point applies to any institution. Its name is on the message, whatever the software has done to the words.

Assistants that answer questions about a source make the same kind of mistake. In a study published in October 2025, 22 public service media organizations in 18 countries tested ChatGPT, Copilot, Gemini, and Perplexity on questions about the news, and 45 percent of the answers had at least one significant issue. That study measured answers about the news. An institution that wants to know what happens to its own letters has to test them.

What the sender controls

An institution cannot govern the software its customers use. It can govern its own sentences. The practices that help a summary are ones plain language already asks for, and the second reader makes five of them more urgent.

Lead with the decision and the action. Say what happened, what the person must do, and by when, before anything else.

Put each deadline next to its action, as a date. “Appeal by March 3” is one fact, and a summary can carry it. “Within 30 days of the date of this notice” depends on a second date that the summary may leave out.

Use one name for one thing. If a letter calls the same step an appeal in one paragraph and a reconsideration in the next, a summary may treat them as two steps.

Keep required steps in the body of the message. A step that appears only in an attachment, a table, an image, or the fine print may not reach the person at all.

Write the subject line as the summary you want. It is the one summary the institution still writes itself.

How to test it

Treat the second reader the way the permission boundary treats an AI system: write down what has to come through, then test for it.

Choose the five messages with the most at stake, such as a denial, a deadline, a change in terms, a safety instruction, and a notice that ends something. Run each one through the summaries your customers are likely to see: an inbox summary on a phone, a Gmail thread summary, and a general assistant asked, “What does this letter want me to do?” Then check whether each summary keeps four things: the decision, the action, the deadline, and the consequence of missing it.

When a summary drops one of them, rewrite the letter. Move the missing fact up, give it a sentence of its own, and test again.

Keep a record of what was tested, with which tools, on what date, and what changed. Summaries change when the software updates, so the test has to be repeated, and the person who owns the institution’s voice should own the test.

The claim

The definition of Voice Governance ends with a test: whether the recipient can act correctly. That test now applies to the version of the message the recipient actually reads, which may be three lines written by software the institution does not control.

Write every consequential message so that even its shortest version tells the person what to do, and by when. §


This is the fourth essay in the Voice Governance framework. Also in the series: What Is Voice Governance? (July), The Permission Boundary (August), and Voice Literacy (September).

Not sure where to start? Send one communication and we will return a short read at no charge.

Request a Voice Audit