Answers to Selected Exercises

A worked key for a representative subset of the book's exercises — enough to calibrate your judgment, not a complete solution manual.

How to use this key

Writing is learned by writing, so most of this book's exercises ask you to produce or revise text, and most have no single correct answer. This appendix does three things:

Answers the Part A (conceptual / "analyze this") questions for a selection of chapters. These have right answers — you should be able to name the defect, the principle, or the IMRaD section — and checking yours against ours is a fast way to confirm you read the chapter, not just skimmed it.
Gives one Part B ("revise this") model answer per covered chapter. A model is a strong answer, not the answer. Yours can differ in wording and still be excellent; what matters is that it fixes the named defect and that you can say which principle drove each change. Read the model, then re-grade your own.
Points you to the self-assessment rubric for the open-ended Part C / D / E / M tasks. Those are graded by rubric, not by key — a "Write the bad-news email" task has thousands of good answers and no canonical one. The rubric lives at the bottom of each chapter's exercises.md; this appendix tells you what the grader (you) should be looking for, and adds a note where the chapter's own rubric needs sharpening.

Coverage is deliberately selective. This key works 15 chapters spanning all nine parts — enough that every part of the book has a worked example, and enough variety (diagnosis, revision, structure, citation, data, slides, requirements, ethics, the capstone) that the method of self-grading transfers to the chapters not covered here. The chapters worked below are 2, 3, 4 (Part I); 6, 8, 11 (Part II); 13 (Part III); 19, 21 (Part IV); 25, 27 (Part V); 30 (Part VI); 33 (Part VII); and 38, 40 (Parts VIII–IX). For chapters not listed, use the rubric at the end of that chapter's exercises.md; the principles are the same.

A few chapters — notably 6, 13, 27, and 38 — already print answers inline in their exercises.md (in <details> blocks). For those, this appendix adds a model Part B revision and a self-grading note rather than repeating what you can already reveal there.

A standing rule for every revision you check: a revision is right when it (a) removes the named defect, (b) preserves the actual content or message, and (c) is one you can justify by principle ("I cut this because it's a nominalization," not "it felt better"). Justifying by named defect is what transfers the skill to your own drafts.

Part I — Writing Is Thinking

Chapter 2 — Audience

Part A — answers

Each item asks you to name the audience mismatch and the K-R-A-C variable that's off (Knowledge, Role/goal, Action, Context).

A1. Knowledge. Five undefined terms (provision, creds, IdP, SSO, VPC bastion, standup) for a non-technical new hire. The writing isn't bad — it would be fine for a fellow sysadmin — it's mis-set for this reader's knowledge.
A2. Knowledge (in reverse) / Role. The abstract is far under the specialist audience's knowledge — "some interesting findings about a thing we studied" tells expert peers nothing they can evaluate. A specialist conference reader needs the actual finding and method. The vagueness wastes the one place experts decide whether to read on.
A3. Knowledge / Action. Customers don't need (or understand) "null-pointer dereference… commit a3f9c… #1851." They need to know whether they're affected, whether it's fixed, and what to do. The variable most off is Knowledge, but the deeper failure is Action — it gives the reader nothing to do.
A4. Role/goal. A busy VP's goal is the decision, not the derivation. Leading with "let me walk you through the full methodology" inverts what this reader needs first; it serves the writer's sense of thoroughness, not the reader's role.
A5. It works. The writer got Knowledge right (developers know pip), Action right (the first thing is the install command), and Context right (layered — quick example up top, full reference below for the reader who wants it). This is the layering move done well.
A6. Knowledge / Role. For a fellow data scientist, "trust me" is the failure: a peer needs the evidence to verify and build on the claim. The problem is the opposite of A1 — here the writer under-supplies precision for an expert who wants it. ("Churn is up, probably onboarding, trust me" is fine for a hallway aside, not a peer record.)
A7. Knowledge — and the stakes make it dangerous. A safety notice to residents must be plainest of all, and this one hides the action ("consider evacuation protocols," "pursuant to §4.2") behind regulatory register. When the stakes are physical safety, an audience mismatch can hurt someone; the action ("leave the building now") must be unmissable.
A8. Context. The writer forgot the message will be forwarded. "The vendor totally screwed us again, classic them" might be fine to a trusted peer, but written to a manager who will forward it up, it becomes a liability. The forgotten principle: write for the secondary reader too — assume forwarding.

Part B — model answer (B1, for a non-technical executive)

Original: "We deprecated the v1 endpoint; clients hitting it now receive a 410, so any unmigrated integrations will fail until they adopt the v2 schema before the EOL date."

Model revision: "Any customer still using the old version of our API (v1) will stop working until they upgrade to v2. We need to make sure our top integration partners have migrated before the March cutoff, or they'll see outages."

Variable optimized for: Knowledge (dropped "410," "schema," "EOL," "deprecated" — none survive for this reader) and Action (the executive now sees the risk and the implied next step: get partners migrated before the deadline). Note what's preserved: the actual consequence (things break) and the deadline. We didn't "dumb it down"; we changed what leads and which terms survive for a reader whose job is the business risk, not the HTTP status code.

Open-ended tasks (rubric)

For Part C (produce the email / profile / reply), Part D (the four-audience translation, the Challenger counterfactual), and Part M/E, grade against the rubric at the foot of chapter-02-audience/exercises.md. The load-bearing checks:

Audience fit: could the piece not be swapped for a different reader? If it reads generically, it failed — that's the whole chapter.
Right lead: recommendation for a decider, method/precision for a peer, hook for the public.
The marquee task (D1): a strong four-audience answer produces four documents that share almost no sentences. If your four versions differ only in vocabulary, you adapted words but not structure and lead — redo, changing what each one opens with.

Chapter 3 — Clarity

Part A — answers

A1. (a) Empty opener ("It is important to note that"). (b) Passive hiding the actor + nominalization ("a decision… will be made"). (c) Abstraction / jargon-padding ("sub-optimal performance characteristics" = "slow"). (d) Wordy connective ("Due to the fact that" = "Because"). (e) Expletive construction ("There are several factors that" → "Several factors…").
A2. (b) is clearer. The single move: the nominalization "Utilization… resulted in an improvement" became a verb with a real subject — "The new framework improved." Characters as subjects, actions as verbs.
A3. Correct passive: the samples are the legitimate topic, the agent (whoever stored them) is irrelevant and obvious, and the sentence keeps the focus on the experimental object. Passive earns its place when the actor is unknown, unimportant, or genuinely not the point.
A4. The buried actor is we (or "the team"): "It was determined that the deadline could not be met" hides who determined it and dodges ownership. Cost: evasion plus padding — "We can't meet the deadline" is honest and half the length.
A5. (a) "advance" — planning is already forward-looking. (b) "end" — a result is already an end. (c) "completely" — eliminate is already total. (d) "past" — history is already past. (e) "unexpected" — a surprise is by definition unexpected.
A6. It fails the "so what?" test. The sentence only announces that another section is coming ("we will now turn our attention to a discussion of the methodology"); it carries no information the heading doesn't. Cut it — start the methodology.
A7. To the database engineer it's a door: "full table scan" and "covering index" are precise shared terms that speed understanding. To the non-technical PM it's a wall: the same words block a reader who doesn't share them. Same sentence, opposite effect — the skill is knowing which audience you have.
A8. "Optimize per spec before merge" is concise but unclear: optimize what, against which spec, and what counts as done? Concision removed words but not ambiguity — proof that concision and clarity are different properties. A clear version names the object and the standard ("Tune the query to meet the 200 ms latency target in the spec before merging").

Part B — model answer (B6, the composite "before")

Original: "It is generally the case that the implementation of new procedures within an organization will, more often than not, encounter a certain degree of resistance on the part of those individuals who are tasked with the adoption of said procedures, due in large part to the fact that change of any kind tends to produce a level of discomfort." (52 words)

Model revision: "People usually resist new procedures because change is uncomfortable." (9 words, ~83% cut.)

Defects removed: empty opener ("It is generally the case that"); nominalizations ("the implementation of," "the adoption of said procedures" → people adopting); hedge-stacking ("more often than not," "a certain degree of," "in large part"); the wordy connective ("due… to the fact that" → "because"); abstraction ("a level of discomfort" → "uncomfortable"). Content preserved: the claim that people resist new procedures and the reason. Nothing of substance was lost — only the 43 words that carried none of it.

Open-ended tasks (rubric)

Use the rubric at the foot of chapter-03-clarity/exercises.md. Key checks: did you cut ≥30% on "revise" tasks without losing a fact; is every surviving passive justified by one of the three legitimate jobs; can a reader draw, number, or point at your key claims (concreteness); did you keep one load-bearing hedge rather than over-cutting into terseness? For the three-audience task (D1), the same warning as Chapter 2 applies: vocabulary changes are not enough — the lead should change with the reader.

Chapter 4 — Structure

Part A — answers

A1. The forecasting statement is weak: "Section 2 reviews background… Section 5 concludes" is a table of contents in prose, telling the reader where things are but not what they say. A good forecast previews the content and the conclusion ("We recommend X; the case rests on three findings, covered in turn"), so a reader who reads only the forecast still gets the gist.
A2. No — a reader hunting for the cost estimate can't find it from Overview / Analysis / Considerations / Conclusion. The failure is uninformative headers: they name document machinery, not content. Informative headers ("Estimated cost: $480K over two years") would let the scanner jump straight there.
A3. Yes — those five topic sentences (latency rose → team paged → first hypothesis → fix cut p95 87% → recommend making it permanent) form a usable map; reading them alone tells the story. That's the test of good topic sentences: the first sentences of consecutive paragraphs should reverse-outline the document.
A4. (1) Prominence — "things are mostly fine" buries the one fact that matters (data is behind) under reassurance. (2) Parallelism — frontend/API/data are reported in three different shapes and orders. (3) Scannability — it's a vague prose blob with no headers, list, or lead; a scanner gets nothing.
A5. It leads bottom-up (the narrative of how the writer discovered the bug) and ends with the actual finding. For a bug report, that's the wrong choice: the genre wants the conclusion first (the discount API 500s for carts over $1,000, blocking checkout), with the investigation narrative demoted or cut. Bottom-up suits discovery writing, not a report someone must act on.
A6. Prose is the wrong tool for a sequence of discrete actions. "Begin by installing… after which… and then… before finally…" hides four ordered steps inside one sentence; a reader performing them can't track their place. A numbered list is the right structure — discrete, parallel, sequential items.
A7. The reviewer is wrong, and the concept is layered structure. An abstract and an introduction serve different readers and depths: the abstract states the result for the scanner; the introduction can build context first for the reader who has committed to the full paper. Leading the abstract with the finding and not leading the introduction with it is not inconsistent — it's serving two reading modes.
A8. Every sentence is clear, but the paragraph is hard to scan because it mixes unordered, non-parallel criteria (pricing, support, contract length, performance, compliance, onboarding) with no structure and no signal of what the reader should do with them. It's a decision input presented as a flat list of clauses; a table (or a lead recommendation) would let the reader compare. The structural problem: the reader has to do the organizing the writer skipped.

Part B — model answer (B1, flip it top-down)

Original: "We tested the new caching layer over two weeks under production-like load, measuring hit rate, memory use, and tail latency across three traffic patterns. After analyzing the results and comparing against our current setup, we found that the new layer improves p99 latency by 40% with no increase in error rate, and we recommend rolling it out."

Model revision: "We recommend rolling out the new caching layer: it cuts p99 latency by 40% with no increase in error rate. We tested it over two weeks under production-like load across three traffic patterns, measuring hit rate, memory use, and tail latency against our current setup."

Principle applied: inverted pyramid / BLUF. The recommendation and the decisive result now lead; the methodology — which was hogging the first (most valuable) sentence — moves to support. A reader who stops after sentence one still has the conclusion. Nothing was cut; the order changed to serve a scanning reader.

Open-ended tasks (rubric)

Grade Parts C/D/E against the 7-dimension rubric at the foot of chapter-04-structure/exercises.md (bottom-line-first, scannability, right tool, hierarchy, parallelism, layering, audience fit; ≥24/28 = sound). For the reverse-outline task (D4), the deliverable is the diagnosis — a buried conclusion, a pointless or overloaded paragraph, a broken flow — plus the two highest-leverage edits, not a full rewrite.

Part II — The Building Blocks

Chapter 6 — Sentences That Work

Part A and Part B already have full answers inline in chapter-06-sentences/exercises.md (reveal the <details> blocks). Use those to self-check. Below is a second model for the trickiest revision, plus a self-grading note for the produce-and-judge tasks.

Part B — model answer (B5, fix the rhythm, not the grammar)

Original (correct but unreadable, ~50 words): "The new caching layer, which was designed to reduce database load and that the team had benchmarked extensively before the rollout to confirm that it met the latency targets that had been agreed upon with the product team, was deployed on Tuesday."

Model revision: "The new caching layer was deployed on Tuesday. The team had designed it to reduce database load and benchmarked it extensively beforehand, confirming it met the latency targets agreed with the product team."

What changed and why: there is no grammar error here — the original is a single grammatically valid sentence. The defect is sentence variety / suspended structure (§6.7): a 13-word subject–verb gap forces the reader to hold "The new caching layer… was deployed" across 30 words of subordinate clause. The fix splits one overloaded sentence into a short one (the news) and a medium one (the support), restoring rhythm. This is the lesson that correctness and readability are different axes — a sentence can be flawless and still exhausting.

Self-grading note (Part C/D)

For C3 (audit your own 60–80-word paragraph against the 20 errors) and E2 (build your error signature), the deliverable is honest self-diagnosis: name your errors by family (orphan this, expletive, dangling modifier, comma splice), not by vague feel. The value is identifying the handful you commit repeatedly. A strong answer to D1 ties a grammar error to a concrete consequence (a misread instruction, a deletion script that removes the wrong files), not merely "looks unprofessional."

Chapter 8 — Paragraphs That Flow

Part A — answers

The vocabulary to name each failure: unity violation, missing/buried topic sentence, given-new reversed, false transition, cohesion vs. coherence, too long.

A1. Unity violation (two interleaved ideas). The paragraph alternates between what the parser does and facts about the lexer being written in Rust. Two topics are braided together; each deserves its own paragraph, or the Rust facts should be cut as foreign to "how the parser works."
A2. False transition. "However" signals contrast, but "all 4 million rows transferred without error" agrees with and elaborates "completed successfully" — there's no contrast. The right connective is none, or "Specifically" / "In all."
A3. Two problems: (1) a run-on / too-long sentence chained on "and… and… and" that should be several sentences; (2) buried information — the actual point (the hit rate dropped below 70% after a misconfigured TTL) arrives last, trailing six clauses of setup. It's one idea per paragraph, but the sentence engineering hides the news.
A4. The failure is coherence, not cohesion. Each sentence is locally clear and they share a topic (the study), but there's no controlling idea connecting "results inconclusive / small sample / miscalibrated instrument / three recommendations / funding source" into a single point — and the funding sentence is a unity violation besides. Cohesion (local connection) can be fine while coherence (a global point) is absent.
A5. No — "There are several things to consider" predicts nothing; it's a content-free topic sentence. The paragraph is actually about the deployment's prerequisites. A working topic sentence: "The deployment has three prerequisites: database access, a valid API key, and 2 GB of free disk."
A6. "Therefore" is wrong: a confirmation email being sent does not logically follow as a consequence of server-side validation — it's the next step in a sequence. The real relationship is sequential ("Then" / "Next"), not causal.
A7. Version (ii) honors given-new. You can tell because it opens with what's already established or easily grasped (we parallelized the test suite) and ends on the new payoff (a 22% cut in build time). Version (i) opens with the new result ("A 22% reduction…") before the reader knows what produced it — given-new reversed.

Part B — model answer (B1, reorder for given-new)

Original (nearly every sentence opens with new information): "A redesign of the search indexing service is proposed here. Higher memory usage during indexing is the main drawback. Faster query response—about 3× on large datasets—is the main benefit. A one-week migration is required to switch over. Backward compatibility with the existing query API is preserved by the new design."

Model revision: "We propose redesigning the search indexing service. The redesign's main benefit is faster query response — about 3× on large datasets; its main drawback is higher memory use during indexing. Switching over requires a one-week migration, but the new design preserves backward compatibility with the existing query API."

Principle applied: the given-new contract (§8.3). Each sentence now opens with something already established (the redesign, then "its" benefit/drawback, then "switching over") and ends on the new information. No facts were added or removed — only the information order within each sentence changed, so the paragraph reads as a current instead of a series of cold starts. Note the bonus fix: the floating passives ("is proposed," "is required," "is preserved by") became active where it improved flow.

Open-ended tasks (rubric)

Grade Parts C/D/E against the five-row rubric at the foot of chapter-08-paragraphs/exercises.md (unity, topic sentence, given-new flow, transitions, length/fit). The reading-aloud test is decisive: a paragraph is ready when you don't stumble at any seam. For D1 (the paragraph that flows beautifully and says nothing), the diagnosis must name cohesion intact, coherence broken, and the rewrite must add a controlling idea the original lacked — you can't fix a missing point by reordering.

Chapter 11 — Citing Sources and Avoiding Plagiarism

Part A — answers

A1. The sentence cites nothing real — "Studies have shown that…" is the weasel phrase doing the damage. It asserts authority ("studies") without naming a source a reader could check. Either cite the specific study or drop the appeal to evidence. (This is the chapter's honesty test turned on a single sentence.)
A2. The problem is inconsistent citation style (entry [1] is roughly APA-ish, [2] is IEEE-ish) — not dishonesty, but a craft failure. To a reviewer it signals carelessness: if the references are sloppy, what about the data? Pick one style and apply it uniformly.
A3. Citing the blog post instead of the article it summarizes risks propagating an error you never checked — the blog may have misread the study, and you've now inherited and amplified that misreading under your own name. Cite the primary source you actually read; if you only read the blog, you can't vouch for the finding.
A4. Inappropriate (over-citation). "Water is composed of hydrogen and oxygen" is common knowledge in any general or scientific context; citing Pauling for it is citation noise that signals the writer doesn't know where the common-knowledge line sits. Cite contested or non-obvious claims, not settled facts.
A5. Because citation style is a venue convention, and an ACS journal expects ACS style. Correct information in the wrong format still violates the venue's instructions for authors — the editor may bounce it for non-compliance regardless of accuracy. The authoritative source is always the target venue's own guidelines.
A6. In an ML conference paper, no citation needed — self-attention as the mechanism of transformers is common knowledge for that audience. In a general-audience magazine article, the sentence still needs no citation for a claim (it's explaining, not asserting a contested result), but the term needs defining. The principle: the common-knowledge boundary moves with the audience.
A7. The first thing the writer must do is verify the source actually exists and says what's claimed — locate the paper, confirm the authors, volume, pages, and that it supports the cited point. Flawless formatting tells you nothing because fabricated citations are often perfectly formatted — the format is the easy part for an AI to generate; the existence is what must be checked.
A8. It risks (1) mosaic/patchwriting if the sentences echo the source's phrasing, and (2) under-citation / misattribution if a single end-of-paragraph citation can't tell the reader which claims came from the source. Tell them apart: patchwriting is a wording problem (your sentences track the source's); under-citation is a signposting problem (the reader can't see where the source's contribution starts and stops).

Part B — model answer (B1, fix the patchwriting)

Source (Zinsser): "The secret of good writing is to strip every sentence to its cleanest components…" Student's patchwriting (to fix): "The key to strong writing is to reduce every sentence to its cleanest parts. Every word that serves no purpose, every long word that could be a short one…" (tracks the source clause-by-clause with synonyms swapped)

Model honest paraphrase: Zinsser argues that good writing comes from rigorous subtraction: the writer's job is to remove every element of a sentence that does no work — redundant words, needlessly long words, adverbs that merely repeat the verb, and evasive passives — because each of these quietly drains a sentence's force (Zinsser, 2006).

Model version using a short quote for the distinctive phrase: Zinsser's core advice is to "strip every sentence to its cleanest components" (Zinsser, 2006) — to treat concision as the removal of anything that weakens the line, from redundant words to evasive passives.

Principle: an honest paraphrase reproduces the idea in your own sentence structure — a reader couldn't reconstruct Zinsser's wording from it — and still cites him. The patchwritten version fails because it follows the source clause-by-clause; swapping "secret/key," "components/parts," "no function/no purpose" is not paraphrasing, it's disguised copying. Where a phrase is too distinctive to recast ("strip every sentence to its cleanest components"), quote and mark it rather than launder it.

Open-ended tasks (rubric)

The style-conversion tasks (C1, C2) have a near-objective standard — check every version for correct information (authors, title, year, venue, pages all present and right) and correct mechanics per style (brackets vs. parentheses vs. superscript; year placement; author abbreviation), and verify against the authoritative manual for each style, not just a reference manager's output. The AI/integrity reasoning tasks (B5, C4, D1, D2, D5) are graded by the rubric at the foot of chapter-11-citing-sources/exercises.md: a strong answer names the specific integrity principle (authorship, fabrication, outsourced thinking, novelty/disclosure) and lands on an actionable rule (verify, disclose, cite yourself) — the deepest answers connect the line back to Chapter 1 (the line is crossed when the thinking you present as yours wasn't yours).

Part III — Academic and Scientific Writing

Chapter 13 — Lab Reports and Technical Reports

Part A and Part B already carry full answers and rubrics inline in chapter-13-lab-reports/exercises.md (reveal the <details> blocks). Use those for the IMRaD-labeling and editorializing items. Below is a consolidated model for the centerpiece revision (B5) and a self-grading note, since that task — converting an academic-ordered opening into a workplace executive summary — is the one most readers get half-right.

Part B — model answer (B5, academic order → executive summary)

Original (method-first, conclusion last): "Over the past quarter we evaluated our incident-response process by reviewing 47 incidents… interviewing eight on-call engineers… and benchmarking against three peer companies… After this analysis, we found that alerting gaps were the leading cause of slow detection, and we recommend investing in expanded monitoring."

Model revision: "Recommendation: invest ~$120K this quarter in expanded monitoring and alerting. Alerting gaps were the leading cause of slow incident detection — responsible for 28 of the 47 incidents we reviewed and adding a median 40 minutes to detection time. Mean time to resolve is now 2× our peer benchmark, driven almost entirely by how late we detect. We request approval by the end of the month so procurement can start next quarter. (How we found this: a review of 47 incidents over the past year, eight on-call interviews, and benchmarking against three peers — detail in the appendix.)"

Principle: §13.8 — for a decision-maker, lead with the recommendation and the ask-with-deadline, demote the methodology to one line or an appendix. The original spent its first and most valuable sentences on how the work was done; a director needs what to do in sentence one. Note the discipline that doesn't change: the numbers are still there, the claim is still calibrated to the evidence. We changed order and emphasis, not honesty.

Self-grading note

The recurring failure on B-series items is leaving editorializing in the Results (every judgment word — "beautifully," "clearly," "surprisingly," "proves," "demonstrates" — must move to the Discussion) and over-claiming in the Discussion (an n = 12 single-baseline study "suggests," it does not "prove superiority"). The acid test for any Results passage you write (C1, C3): could a skeptic who disagrees with your interpretation still accept every sentence? If not, an interpretation has leaked into the observations.

Part IV — Professional and Workplace Writing

Chapter 19 — Emails That Get Read

Part A — answers

A1. Two failures of "Quick question" on a 400-word budget request due Thursday: (1) it misrepresents the content (it's neither quick nor a question), so the reader mis-triages it; (2) it carries no topic and no urgency, so it can't survive an inbox scan or signal a Thursday deadline. Cost: the email gets deprioritized and the deadline is missed.
A2. The principle is purpose first (lead with why you're writing). Burying the purpose in sentence five behind "I hope you're having a wonderful week… the spring weather…" forces a busy reader to dig for the point. The first sentence should have stated the request or topic; warmth can ride alongside it, not in front of it.
A3. Reply-all is wrong here. "Thanks, looks good!" is relevant to one person, not sixty; it generates 59 useless notifications. The question to ask before clicking reply-all: does everyone on this thread need this? If not, reply to the sender.
A4. Three things that make the ask ignorable: (1) no specific action (vague "hear your thoughts"); (2) no deadline ("at some point," "no rush at all"); (3) so much hedging ("if you happen to," "not too much trouble," "maybe") that it signals the request doesn't matter. An easy-to-ignore ask gets ignored.
A5. The reader needs the new date, stated plainly — and it should appear early, not buried in the last line behind hedges ("might slip a bit, possibly into next week sometime"). Bad news needs the fact up front and a concrete revised date the reader can plan around.
A6. Silence is worst because it leaves the asker blocked and guessing — they can't plan, can't escalate, can't move on, and waste days nudging. A thirty-second "No, I can't take this on — try Priya" would have freed them immediately. A clear no is a kindness; silence is the cruelty disguised as conflict-avoidance.
A7. The channel may be fine, but the structure fails a scanning reader. The subject "Re: Re: Re: thoughts?" tells the recipient nothing, and "just following up on the thing from earlier" assumes context they may not have. They can't tell what "the thing" is or what's being asked. Fix the subject (state the topic) and restate the ask explicitly.
A8. The threshold concept: "complete" is not "effective." The email contains every fact but dumps them in an unstructured run with no lead, no priority, and no clear ask — the reader can't tell what matters (the untested rollback plan? the legal review? the offsite?) or what they're supposed to do. Completeness is the writer's checklist; effectiveness is the reader's experience.

Part B — model answer (B3, the buried request)

Original (subject "hello!", ask buried in a 90-word windup about the rebrand and uncertainty): "Hi Sana, I hope your week is going great! … if there's any chance you could point me to the most recent versions whenever you get a moment, that would be super helpful…"

Model revision:

Subject: Need latest Settings-page design files to start dev (by Thu?)

"Hi Sana — could you point me to the current design files for the Settings page? I'm starting development on it and want to make sure I'm building from the latest versions (I think mine may predate the last review). If you can send them by Thursday, I can start on schedule. A link to the folder is all I need — thanks!"

Principles applied: the five-part request anatomy. Ask first and specific (the design files, named); brief why (starting dev, mine may be stale); real deadline with a reason (Thursday, to start on schedule); friction removed ("a link to the folder is all I need"); warmth alongside, not in front (one "Hi Sana," one "thanks," no paragraph of apology). The subject line now survives triage. Length dropped from ~90 words to ~60, and the reader can act in one read.

Open-ended tasks (rubric)

Grade Parts C/D against the 7-dimension rubric at the foot of chapter-19-emails/exercises.md (subject line, purpose first, scannable/pruned body, the ask, hard-email structure, tone, channel fit; ≥24/28 = ready to send). The two hardest tasks: C3 (bad-news email) — the news must come early and framed, context owned in one sentence (not a paragraph of excuses), the plan-with-a-date leading; and C4 (the "no") — acknowledge → clear no → brief reason → real door open. A "no" that never actually says no, or that buries the decline under guilt, fails the rubric.

Chapter 21 — Workplace Reports

Part A — answers

Name the principle: exception-based reporting, BLUF, outcomes-not-activities, blameless framing, owner+date, minutes-not-transcript.

A1. Every word fails because it's all activity and affect, zero information: "productive week," "a lot of things," "good progress overall" name no outcome, no exception, no decision. A status update exists to surface what changed and what needs attention; this surfaces neither (violates exception-based reporting and outcomes-not-activities).
A2. The failure is "watermelon" reporting — green on the outside, red on the inside. Eight weeks of all-🟢 followed by a surprise three-week slip means the status colors weren't honestly tracking reality; the green was reassurance, not signal. Healthy reporting makes a slipping item turn amber before it ships late.
A3. Three problems in "15:40 — The on-call engineer finally noticed the obvious memory problem that should have been caught much earlier": (1) blame ("finally," "should have been caught" point a finger); (2) editorializing ("obvious") in what should be a neutral timeline; (3) no factual content — a timeline entry should state what happened ("15:40 — on-call engineer identified memory exhaustion as the cause"), not judge it.
A4. Not usable. "Discussed the budget for 20 minutes and considered several options before deciding to defer" records the conversation, not a decision or action. Minutes capture what was decided and who owns what next — here: "Decision: budget deferred to next week's meeting. Action: [owner] to prepare the three options by [date]." (minutes-not-transcript)
A5. "Going forward, we'll be more careful about testing" will never happen because it has no owner, no specific action, and no date — "be more careful" is a wish, not a task. Rewrite as a tracked corrective action: "Add an automated pre-production test gate to the deploy pipeline. Owner: [name]. Due: [date]." (owner+date)
A6. A trip report that opens with venue, speaker bios, and lunch options buries the value under travelogue — chronological narration instead of value-first reporting. The recommendation (or key takeaway worth the trip) belongs in the first line; the itinerary, if it appears at all, goes to the bottom.
A7. "Made significant headway" is not an outcome — it's an activity in disguise (how much headway? is it done?). If the work is done: "Shipped the authentication system; users can now log in via SSO." If it genuinely isn't: "Authentication system 70% complete; SSO works, password reset still in progress, on track for Friday." The Done section is for finished outcomes only.
A8. Beyond the loaded labels, it fails as a feasibility study because it offers no honest baseline and no real comparison — "do nothing, which would be bad" isn't a fairly evaluated option, it's a strawman. A feasibility study must state its criteria before comparing, and evaluate each option (including the status quo) honestly against them, or the recommendation is predetermined.

Part B — model answer (B3, blameful root cause → neutral timeline + blameless cause)

Original: "At 9:15 Dev carelessly deleted the production index, which he obviously shouldn't have done, and this took down search for everyone."

Model revision:

Timeline: 09:15 — A production index was deleted during a manual maintenance operation, taking search offline for all users.

Root cause: The maintenance procedure allowed a production index to be dropped directly from an interactive session, with no confirmation step, no dry-run mode, and no separation between the staging and production consoles. A single mistaken command therefore had immediate, irreversible production impact.

Principles applied: blameless framing + system root cause. The timeline states the fact neutrally — no name, no "carelessly," no "obviously" — and the root cause attacks the system gap (no confirmation, no dry-run, no console separation) rather than the person. This isn't softness: the blameless version produces better corrective actions (add a confirmation step; separate consoles) because "Dev should be more careful" fixes nothing, while "the procedure allowed a one-keystroke production deletion" points straight at what to change.

Open-ended tasks (rubric)

Grade the Write/Synthesis tasks against the six-row rubric at the foot of chapter-21-workplace-reports/exercises.md (headline/BLUF, exception focus, outcomes vs. activities, owners+dates, blamelessness, conciseness). The centerpiece, C1 (compress a 500-word update to an exception-based dashboard), is graded on whether you (a) cut the word count by at least half while increasing useful information, (b) compressed the green items to one line each and gave detail only to amber/red, and (c) surfaced the single real decision (the gateway cutover) in a "Decisions Needed" line. The most common miss: treating routine and exceptions as equally weighted.

Part V — Software and Data Writing

Chapter 25 — README Files, API Docs, and Developer-Facing Writing

Part A — answers

A1. The core failure is burying the front door: a developer arriving at a README wants to know what it is and how to install and use it, and this opens with 600 words of philosophy before the first install command. The one change that helps most: move a one-line description + install command + a runnable example to the very top; demote the philosophy to a "Background" section or cut it.
A2. "Retrieves an order. Returns the order data" is missing at least: (1) the path/query parameters and which are required; (2) authentication (does it need a token?); (3) the response schema — what fields, what types, an example body; (4) the error responses (404 if the order doesn't exist, 401/403, etc.). A developer can't integrate against it without these.
A3. As a changelog (vs. a commit log), the entry fails because it's written for the committer, not the upgrading user: "merge branch feature/refactor," "fix," "bump" describe internal git mechanics, not user-visible changes. It should be grouped by type (Added/Changed/Fixed/Removed), describe changes in user terms, lead with the breaking change ("remove old API"), and give a migration path for it.
A4. README X gets more users. The principle: a README is the product's front door; optimize for time-to-first-success. X gives a stranger what-it-is + install + a runnable example in seconds; Y makes them wade past a logo, twelve badges, and three philosophy sections to find the install command under heading 14. Equal code, unequal adoption.
A5. The missing Consequences section is the one that most undermines an ADR because the why-it-might-hurt is exactly what a future maintainer needs. Context and Decision tell them what was chosen; Consequences (the trade-offs accepted, the costs, the things now harder) are what stop them from naively undoing the decision — or what tell them when to revisit it.
A6. When a reader copies the wrong curl (no auth header, /search instead of /v2/search), it fails immediately and they blame the tool, not the doc — and a doc that actively misleads is worse than none. The author violated the principle that examples must be runnable and correct as written (and ideally tested), because readers copy-paste literally.
A7. "Make sure your code is high quality and follows our conventions" leaves a new contributor no closer because it's abstract — it names a standard without operationalizing it. What helps: the concrete steps (how to set up the dev environment, how to run the tests, what linter/formatter to use, the actual submission process). Contributing docs are instructions, and instructions must be specific and performable.
A8. (a) "Blazingly fast, highly flexible, enterprise-grade" carries no information — they're unverifiable intensifiers (the Chapter 7 concept: empty/abstract diction, "no-voice" marketing register). (b) "Parses 50 MB log files in under 200 ms; pluggable format definitions" carries information — a concrete, checkable claim. Specifics inform; adjectives assert.

Part B — model answer (B1, the motivation wall)

Original (opens with a paragraph on "the problem of configuration management… for decades…"): the tool, confdeck, loads and validates config from YAML and environment variables.

Model revision (README top section):

```markdown

confdeck

Load and validate your application's configuration from YAML files and environment variables — with clear errors when something's missing or wrong.

Features

Single source of config from YAML + environment variables

Validates required fields and types on load; fails fast with a readable error

Works from a single service to a fleet — same API everywhere

Zero config to start; declarative schema when you want it

Installation

bash pip install confdeck # requires Python 3.9+ ```

Principle: §25.2 — a README leads with what it is (one line) and the path to using it (features + install), not a meditation on the problem space. The "plagued software teams for decades" philosophy is moved down or cut; a developer can now tell in five seconds whether confdeck is for them and how to install it. The feature bullets are concrete (what it does), not adjectives ("powerful, flexible").

Open-ended tasks (rubric)

Grade the produced documents (Part C) against the dimension-by-dimension rubric at the foot of chapter-25-readme-api-docs/exercises.md, scored 0–2 per dimension. For a README (C1, C4) the single most important dimension is time-to-first-success — is there an install command and a runnable example a stranger could use in under five minutes? For an API endpoint (C2) the most-skipped, most-needed part is the errors table (status + stable code + plain-language meaning); the source-independence test is whether a developer could use it without reading your code. For an ADR (C3), the honesty test is whether Consequences includes the negative trade-offs, not just benefits.

Chapter 27 — Writing About Data

Part A and Part D already carry discussion notes inline in chapter-27-writing-about-data/exercises.md (reveal the <details> blocks), including the observation–interpretation–recommendation ladder labels and the causation cautions. Use those to self-check. Below is a model for the centerpiece revision (D1) — the methodology-first memo — and a self-grading note, since converting a method-first memo to recommendation-first is the chapter's signature task.

Part D — model answer (D1, methodology-first memo → recommendation-first)

Original (to VP Product, subject "Feature-usage analysis"): opens with "I pulled product analytics events… ran a clustering analysis… k-means (k selected via the elbow method at k=4)…" and buries the finding (52% vs. 81% retention) in paragraph four, ending "Let me know your thoughts."

Model revision:

To: VP Product Subject: Recommend driving collaboration-feature adoption — our biggest retention lever

"Recommendation: launch an in-product nudge that gets reporting-only accounts to try one collaboration feature. This is our largest retention opportunity.

Why: 41% of our accounts use only the core reporting feature and never touch collaboration tools — and they retain at just 52% over 90 days, versus 81% for accounts that use any collaboration feature. That 29-point gap holds after accounting for account size and tier.

One caveat on confidence: this is a strong correlation, not yet proof that adoption causes retention — so I'd scope the nudge as an experiment we can measure, rather than a permanent change. (Method: a clustering analysis of last quarter's usage across 18,000 accounts; detail and charts below.)"

Principles applied: §27.4 (recommendation-first) + §27.9 (honest about what the data supports). The recommendation and the stakes now lead; the method (clustering, k-means, elbow) drops to a single closing line for the reader who audits it. Crucially, the rewrite keeps the finding intact and calibrates the claim — it flags correlation-vs-causation rather than asserting the nudge will lift retention, and it does not hand the VP the interpretive step with a limp "let me know your thoughts." Same data, reordered for a reader who must decide.

Self-grading note

Across the B and D items the recurring failures are (1) stopping at Level 1 — reporting an observation ("page-load time is 3.2 s," "open rates fell to 16%") with no "so what?" and no recommendation; and (2) over-claiming causation — "mobile users abandon more, so rebuild the app" or "usage causes high LTV," when the data shows only correlation. The discipline: push every finding to a supportable action (Level 3), and where the data can't support a confident action, recommend the next investigative step (an experiment, session recordings) instead of a hunch dressed as a recommendation.

Part VI — Presentations and Oral Communication

Chapter 30 — Slide Design

Part A — answers

A1. Two reasons a "Results" slide with five bulleted findings fails in a talk: (1) it's topic-and-bullets, not assertion–evidence — the title names a topic instead of making a claim, so the slide doesn't tell the audience what to conclude; (2) it makes the audience read while you talk, which the redundancy effect says degrades both — and five findings is five points on one slide, violating one-point-per-slide.
A2. Yes, this is assertion–evidence done correctly: the title is a full-sentence claim ("Our latency dropped 60% after the caching rewrite"), the body is a single directly-labeled visual that proves it, and the presenter uses the slide as intended — the slide carries the what (the result) so the speaker's voice can carry the why (how caching helped). The visual is evidence; the speech is the explanation.
A3. An 8-word title ("System Architecture, Data Flow, and Security Considerations") predicts three slides crammed into one — it names three topics, which means three points. The fix: split into three assertion slides, each making one claim about one of architecture, data flow, and security. (And drop the topic-phrasing for sentence claims.)
A4. The real problem isn't the animation — it's that the slides are bullet lists at all ("it keeps people from reading ahead" only matters if there's a wall of text to read ahead in). The correct fix is to redesign each slide as one assertion + one visual, which removes the reason to fly bullets in one at a time. Fixing the animation treats the symptom.
A5. Violations: rainbow colors distinguished only by a corner legend (color-as-only-channel + forces a legend lookup), heavy gridlines and a 3-D effect (chartjunk, low data-ink), and a y-axis starting at 40 instead of zero. The honesty problem (not just clarity) is the truncated y-axis — it visually exaggerates differences and misleads the viewer about magnitude. The rest are clarity/legibility failures; the axis is an integrity failure.
A6. A good slide. A single large number ("$2.4M") with a one-line label, then a verbal breakdown, is assertion–evidence at its cleanest: the slide makes one point land hard and lets the speaker carry the detail. It passes the back-row test and respects the one-point rule. (It would be lazy only if the number were unexplained or wrong — but here the presenter supplies the breakdown aloud.)
A7. It does not necessarily fail. "10 slides" is a rule of thumb for few points and tight time, not a literal cap — 38 clean one-point slides clicked quickly can be fine, while 10 dense slides can be a disaster. What to actually check: does the talk fit the time, does each slide make one point, and is the type legible? Audit the spirit (few points, big type, tight time), not the slide count.
A8. This is a delivery mistake, not a deck mistake — the slides are clean assertion–evidence. The specific error: reading the slide aloud verbatim adds nothing and triggers the redundancy effect (the audience can read the title faster than you can say it). The assertion title is there so the speaker can expand on it — give the evidence, tell the story — not recite it.

Part B — model answer (B1, topic-and-bullets → assertion–evidence)

Original — Title: "Q3 Performance." Bullets: "Revenue up 12% QoQ · CAC down 8% · Churn flat at 4.1% · Net revenue retention 108%."

Model redesign: You can't make four points on one slide, so pick the one message or split. If the real point is "Q3 was a strong growth quarter," lead with that:

Slide title (assertion): "Q3 was our strongest growth quarter: revenue up 12% with retention improving." Body (single visual): a simple two-bar or trend chart showing revenue QoQ, with net revenue retention (108%) annotated directly on it. CAC and churn move to spoken support ("…and we did it efficiently — acquisition cost actually fell 8%, and churn held flat").

Principle applied: assertion–evidence + one point per slide. The title now states a claim; the body is one visual that proves it; the two secondary metrics are carried by your voice rather than competing as equal bullets. If all four metrics genuinely matter equally, the honest fix is more slides, one point each — not four bullets in a new layout. (The most common failed attempt is reproducing the four bullets in a prettier font; that's still four points on one slide.)

Open-ended tasks (rubric)

Grade the redesign tasks (Parts B/C) against the 0–2-per-dimension rubric at the foot of chapter-30-slide-design/exercises.md (assertion not topic; one point per slide; visual as evidence; legibility/back-row test; audience & restraint; 10 = publishable). For the five-bad-slides task (C1) and the conversion tasks (B1, B4, C2), the single decisive check is whether you chose one message per slide rather than relabeling the bullets — that choice is the chapter, and reproducing the bullets in a different layout is the signature failed attempt. Watch the trap in M8: the six-word ceiling is for topic titles, not assertions — a 12-word assertion like "Our new caching layer cut p99 latency from 2.1 s to 0.7 s under peak load" is correct and should not be trimmed into a topic phrase.

Part VII — Writing for Specific Fields

Chapter 33 — Writing for Engineering

Part A item A9 (the door-system spec) and several B items carry hints inline in chapter-33-writing-for-engineering/exercises.md. Below are answers to the rest of Part A and a model for the flagship rewrite (B7), since making a vague statement into a single testable SHALL is the chapter's signature transformation.

Part A — answers

Name the failure: untestable, compound, modal mush, design-in-requirement, normative/informative blur, orphaned.

A1. "The system shall be highly available and performant" hides at least two requirements (availability, performance), joined by "and" — compound. And both key words are untestable: "highly available" and "performant" name no measurable value or condition. A tester can't pass/fail either.
A2. The compound structure crams three requirements into one sentence ("load fast," "visually appealing," "support dark mode"), and they carry three different obligation strengths: "should load fast" (recommendation), "must be visually appealing" (mandatory — and untestable besides), "ideally would support dark mode" (optional). Split them and assign a correct RFC 2119 keyword to each.
A3. "Will" is modal mush — it could be read as a requirement, a prediction, or a description, and that ambiguity means an implementer can't tell whether encryption is mandatory. The one change that fixes it: use the RFC 2119 keyword that states the obligation — "The system shall encrypt data" (and then specify what data and to what standard).
A4. "REQ-042. The system shall use a PostgreSQL database with a connection pool of 20" puts a design decision in a requirements document — the requirement should state the what (an outcome: e.g., "shall sustain N concurrent connections with p95 latency under X"), and PostgreSQL with a pool of 20 is a how that belongs in the design doc. Baking the implementation into the requirement over-constrains the designer and conflates two documents.
A5. Two problems with "Note: the API gateway should rate-limit requests…": (1) normative/informative blur — it's labeled "Note:" (informative) but contains a binding "should" (normative); a reader can't tell whether it's a requirement; (2) untestable — "rate-limit… to protect downstream services" names no rate, no threshold, no condition. Make it a real requirement with a value, or make it a genuinely non-binding note.
A6. "Approximately 200 g" is a missing specification, not a modest one, because a manufacturer needs a tolerance, not a vibe: is it 200 g ± 5 g, ± 50 g? Without bounds the requirement is unverifiable — there's no value at which it passes or fails. What's actually needed: a target and a tolerance ("200 g ± 10 g").
A7. "Expected result: the feature works as intended" verifies nothing because "as intended" is unmeasurable — it points to no specific, observable outcome. Two testers would reach different verdicts because each supplies their own idea of "intended." A real expected result states the exact observable output ("the confirmation banner displays 'Saved' and the record's status field reads 'complete'").
A8. A well-formed hazard entry has, and this one lacks: (1) a specific hazard (not "could be dangerous" — what hazard: electric shock from exposed high-voltage terminals); (2) the cause/condition (when does it arise); (3) a control stated as a requirement ("the enclosure SHALL…," traced to a test), not "be careful"; (4) severity/likelihood and residual risk. "Technicians should be careful" is an instruction to be lucky, not a control.

Part B — model answer (B7, the flagship rewrite)

Original: "The system should be fast."

Model revision (single testable SHALL): "REQ-014. Under a sustained load of 1,000 concurrent users, the system shall return search results within 500 ms at the 95th percentile."

Verification method (one line): Test — drive the system to 1,000 concurrent users with a load-generation tool in the staging environment and measure response latency; the requirement passes if measured p95 ≤ 500 ms.

Why it's exemplary: the original is untestable ("fast" names no value, no condition) and uses modal mush ("should" — is it mandatory?). The rewrite is atomic (one requirement), testable (a measurable value — 500 ms — at a stated percentile, under a stated condition — 1,000 concurrent users), uses the correct keyword (SHALL for a hard requirement), specifies what not how (it says nothing about caching or database choice), and is traceable (it has an ID and an attached verification method). The test for any requirement: could someone build this, and could someone else prove whether what they built satisfies it? Both answers are now yes.

Open-ended tasks (rubric)

Grade the produced requirements, test cases, and hazard entries (Parts C, and the B-series) against the six-criterion table at the foot of chapter-33-writing-for-engineering/exercises.md: atomic (one thing, no smuggled "and"), testable (a verification method that returns pass/fail), correct keyword (SHALL/SHOULD/MAY in their RFC 2119 sense, not all-SHALL, not modal mush), what-not-how (outcomes, not implementation), traceable (a stable ID that maps to a source and a test), no weak words ("fast," "robust," "user-friendly," "approximately" without a tolerance, "etc."). The single best self-check: could someone build this, and could someone else prove whether they did?

Part VIII — Synthesis

Chapter 38 — Ethics and Responsibility

Part A and the B-series carry a self-check and rubric inline in chapter-38-ethics-responsibility/exercises.md (the Part A self-check names every violation). Use those to verify your diagnoses — A1 overstatement, A2 buried conflict + misleading test conditions, A3 hidden risk/spin, A4 exclusionary language, A5 overstatement from a tiny unblinded sample, A6 false reassurance + omission, A7 lie of omission, A8 definitional cover. Below is a model for a B-series revision and a self-grading note, since "make it honest without gutting the message" is the move readers most often overcorrect.

Part B — model answer (B2, the migration recommendation)

Original (A3): "The migration will be straightforward and low-risk. We recommend proceeding immediately to capture the substantial efficiency gains." (The team's own notes record an unproven dependency on a legacy billing integration and an expected 2–4 week slowdown during cutover.)

Model revision (§38.5 pattern — lead with the recommendation, quantify honestly, surface the one real risk): "We recommend proceeding with the migration this quarter; it should cut our infrastructure costs by roughly 30% (about $40K/year) once complete. One genuine risk to flag: the cutover depends on a legacy billing integration we haven't yet validated, and we expect a 2–4 week slowdown during the transition. We've built that window into the plan, but if the billing integration proves incompatible, the timeline could extend. On balance the gain justifies the risk, and we recommend approval with a checkpoint after the integration is tested."

Why it's right: the recommendation still recommends — we didn't gut the message into "well, it might work, who knows." But the whole passage now leaves a true impression: "straightforward and low-risk" (which contradicted the team's own notes) is replaced by an honest, quantified benefit and the one decision-relevant risk, surfaced rather than buried. This is the chapter's core move: honesty strengthens a recommendation by making it trustworthy. The self-check: if you removed the persuasion entirely, you overcorrected; if you kept a claim the team's own notes contradict, you didn't correct enough.

Self-grading note (and the double-edge tasks)

For the "make it honest" revisions (B1–B6), grade against the self-check at the foot of the exercises: does the whole passage leave a true impression (not just true sentences); is each claim calibrated to its stated evidence (neither inflated nor hedged into mush — B6 is the under-claiming trap); are decision-relevant limitations paired with their consequence; is the legitimate message preserved? For the synthesis tasks (D2, the spin-proposal; D3, the Challenger-three-ways; E2, the ethics of the book's own toolkit), the test in every case is the chapter's thesis: clarity is a tool that can serve the reader's judgment or defeat it — name the specific words that carry the spin (not just "it's vague"), and cite only the verifiable public record for the cases (no invented quotations, dates, or casualty figures).

Part IX — Capstone

Chapter 40 — The Communication Portfolio

Part A — answers

A1. As a front door, "Welcome to my portfolio! I am a passionate, detail-oriented communicator with a proven track record of excellence…" fails because it's all assertion, no evidence, in the empty 'passionate communicator' register — it could front anyone's portfolio and says nothing specific. The two opening sentences should instead answer whose portfolio, on what subject, and why read on — e.g., "I'm a data analyst who writes for non-technical decision-makers. These seven pieces show one finding carried from a technical report to an executive memo to a public blog post."
A2. Three failures of the eight-file folder: (1) no index/front door — a reader doesn't know where to start or what they're looking at; (2) incoherent, unprofessional naming (report_FINAL_v3 (1).docx, "cover letter REAL final.docx") signals carelessness and breaks coherence; (3) mixed, unexplained formats (a screenshot, a draft, an "old" file) with no curation or annotation. Fixes: add an index that interprets each piece; rename everything on a consistent scheme; curate (drop drafts/old files) and annotate.
A3. "I can now communicate effectively with any audience in any format" is a claim with no evidence, and an over-claim — and the failure is riskier in a portfolio than on a résumé because the portfolio contains the proof: a reader can immediately test the claim against the pieces, and any gap between the boast and the work destroys credibility on the spot. The growth narrative must show, not claim ("I learned to lead with the finding — see how the data memo opens with the recommendation, where my Chapter-1 draft opened with method").
A4. The second annotation borrows Chapter 9's interpretive-caption discipline — it doesn't just label the piece ("Technical Report (PDF)"), it tells the reader what to notice and why it's good ("note how the recommendation leads and the methodology is demoted to an appendix"). It does for the portfolio reader what an interpretive caption does for a chart reader: supplies the takeaway instead of leaving them to find it.
A5. Including the rushed seventh piece is the wrong call. The argument for: it completes the range (all seven genres). The argument against, which wins: a portfolio is judged by its weakest piece as much as its strongest, and an unrevised twenty-minute post contradicts the whole "revised at least once" premise (theme: revision is where the writing happens). The deciding principle (§40.1, §40.5): curate for quality and range, not for a checkbox — six strong pieces beat seven with a weak link.
A6. Against theme 7 ("the best writing is invisible"), the elaborate site with scroll animations, a particle background, and a slow custom font puts the packaging in front of the content — the reader notices the wrapper, not the writing, and the slow load actively costs readers. The one situation where the elaborate site is right: when the role itself is about that craft (e.g., a front-end or design-focused position where the site is a work sample). Otherwise, presentation should disappear.
A7. Candidate X likely wins because (1) order leads with strength and ends distinctive — a research-lab reader meets the technical report, proposal, and conference deck first (exactly what the role values), with the blog post last as a range-shower; and (2) curation fits the named reader — X ordered for this audience, while Y sent files in upload order with the least role-relevant piece (the blog post) first. Same writing, but X respects how the reader reads (scanning, deciding early).
A8. The cover letter claims a skill ("learned to lead with the finding") that the very piece it introduces contradicts (three paragraphs of methodology before any result). What's gone wrong: the growth narrative was written as aspiration, not as a description of work the portfolio actually demonstrates. The lesson about when to write the growth narrative: write it last, from the finished evidence — claim only what the revised pieces prove, or fix the piece so it proves the claim.

Part B — model answer (B2, method-first memo opening → recommendation-first)

Original: "To evaluate deployment reliability, we collected incident data across the last two quarters, classified each incident by root-cause category, and computed mean time to recovery for each category before and after the pipeline migration."

Model revision: "Recommend we make the new deploy pipeline the default for all teams: since migrating to it, our mean time to recovery has dropped from 95 minutes to 38. The finding rests on two quarters of incident data, classified by root cause and compared before and after the migration — detail below."

Principle applied: §40.5 / Chapter 27 — recommendation-first. The original opens with how the work was done; the portfolio-grade version opens with the recommendation and the decisive number, demoting the method to a closing clause. This is the exact move the portfolio's data-memo piece must demonstrate, and the cover letter can then honestly point to it as evidence of growth ("compare this opening to my Chapter-1 draft, which led with the method").

Open-ended tasks (the capstone rubric)

The two starred tasks — C2 (assemble and self-assess the portfolio) and C3 (the growth-narrative cover letter) — are the assignment the chapter exists for, and both are graded by the rubrics at the foot of chapter-40-communication-portfolio/exercises.md (and the capstone rubric in part-09-capstone/). The load-bearing checks:

C2: the inventory is honest (drafts marked as drafts; the weakest-dimension column names a specific rubric dimension, not a feeling); self-assessment is dimension-by-dimension, not averaged; every piece was revised at least once, changing meaning or structure (not just spelling), with at least one before/after saved; curation fits a named reader; order leads with strength and ends distinctive; the surface is coherent. Top score: a stranger understands what the portfolio is in thirty seconds, reaches the strongest piece first, and you can name — for every piece — the one revision you made and why.
C3: shows, doesn't claim (every growth assertion points to checkable evidence — a named piece, a place to look); anchored in the Chapter-1-charter-to-now comparison and the saved before/after; honest about the starting point and names one thing still to improve; clear, concrete, short (it performs the post-growth skill while describing the pre-growth state); under-claims relative to the evidence, so the pieces exceed the letter. Top score: a reader who reads only the cover letter wants to read the pieces — and finds them better than the letter promised.

A final word. This key answered the questions that have answers and modeled the revisions that have strong forms, but most of what this book asks you to do — write the email, redesign the slide, assemble the portfolio — is graded by rubric because it has no single right answer, only stronger and weaker work. That is not a gap in the key; it is the nature of writing. The discipline the rubrics enforce is the same one every chapter taught: know your reader, lead with what they need, cut what doesn't earn its place, revise until the prose disappears and only the content remains. Hold your own drafts to that standard, and you won't need an answer key.

See also: Bibliography · the rubric at the foot of each chapter's exercises.md.