Case Study 1 — Three Authors, One Voice: Harmonizing the Quarterly Reliability Report

A worked integration. Fictional but realistic — a composite of the kind of report a platform team produces every quarter.

The Aperture Data Platform team owes its leadership a one-page quarterly reliability report. Maya, the document owner, divided it into three sections by who knows the material: Devon (SRE) on uptime and incidents, Priya (capacity engineering) on load and headroom, and Sam (the on-call lead) on the team's response and what's next. Everyone wrote their part. Here is what landed in Maya's inbox — three sections, three different people writing.

The raw sections (before integration)

Devon (SRE) — Reliability: "We hit 99.95% uptime this quarter against our 99.9% SLO. There were two incidents. The bigger one was a 40-minute outage on the platform on March 12 caused by a bad config push. Both were resolved within SLA."

Priya (capacity) — Load: "It would appear that the system experienced a not-insignificant increase in traffic over the reporting period, on the order of approximately 35 percent, which the infrastructure was, on the whole, able to accommodate without serious degradation, although it should perhaps be noted that a degree of additional headroom analysis may be advisable before one could responsibly characterize the current capacity posture as fully adequate for anticipated future growth. The team expended considerable effort on this assessment."

Sam (on-call) — Response & Next: "Honestly the team crushed it this quarter. On-call was rough during the March 12 thing but everyone rallied. We're in great shape and there's basically nothing to worry about going forward. Next quarter we'll keep doing what we're doing. Maybe look at the config deploy process since that bit us."

Read those three aloud and you can hear three different humans. Devon is crisp and factual. Priya hedges into fog — "would appear," "not-insignificant," "may be advisable," "could responsibly characterize" — and buries a real finding (headroom is uncertain) under qualification. Sam is warm and breezy ("crushed it," "basically nothing to worry about") and contradicts Priya outright: she says headroom needs more analysis before she'd call capacity adequate; he says there's "basically nothing to worry about." There's also redundancy waiting to happen (March 12 will be mentioned twice) and content-free filler in both Priya's and Sam's sections.

The content is all there. The report doesn't exist yet.

The integration pass

Maya runs the five moves from §23.5.

Unify the voice. The target, per the team's style guide, is confident and direct, calibrated to the evidence — Devon's register, essentially. Priya's fog gets calibrated (state the headroom uncertainty as a clear, single caveat, not a cloud of hedges); Sam's breeziness gets professionalized (keep the substance — the team responded well, the config process is a known weak point — drop the slang and the false reassurance).

Unify the terminology. Devon and Priya disagree on the noun: "the platform" vs. "the system." The style guide says the platform. Replace throughout.

Smooth the seams. Three sections become one report with a logical flow: headline reliability → load context → the one real risk → what's next. Each fact connects to the next instead of sitting in its own silo.

Hunt contradictions. The live one: Priya's "headroom may be inadequate for future growth" vs. Sam's "basically nothing to worry about." Reconcile to the precise truth — capacity handled this quarter's load, and headroom for future growth is the open question Priya flagged. Stated precisely, that's not a contradiction; it's a current-state-plus-open-risk. Sam's "nothing to worry about" was simply wrong, an over-compression; Priya's fog hid a real point. The integrated version surfaces the point clearly and drops the false reassurance.

Cut redundancy. March 12 is mentioned once (in reliability), then referenced, not re-described, when the config process comes up under "next." The filler — "expended considerable effort," "the team crushed it" — goes entirely; it's morale, not information.

The integrated report (after)

Aperture Data Platform — Q1 Reliability Report

The platform exceeded its reliability target this quarter: 99.95% uptime against a 99.9% SLO. Two incidents occurred, both resolved within SLA; the larger was a 40-minute outage on March 12, caused by a bad configuration push.

Traffic grew about 35% over the quarter, and the platform absorbed it without serious degradation. One open question remains: current headroom is adequate for today's load but not yet confirmed for projected future growth — a capacity analysis is scheduled for early next quarter to size that gap.

The team's incident response was strong, including during the March 12 outage. Our one clear improvement target follows directly from that incident: the configuration deploy process, which lacked a safeguard against the bad push. Hardening it — staged rollout and an automated config check — is next quarter's priority alongside the headroom analysis.

What changed, and why it matters

Three voices became one. The report now reads as though a single, capable person wrote it — which is exactly the point: the reader (leadership) should never sense that three people contributed. The fog lifted: Priya's buried headroom concern is now a single clear sentence a director can act on. The false reassurance is gone: Sam's "nothing to worry about" would have actively misled leadership, and the integration replaced it with an honest, specific risk and a plan. The contradiction dissolved not by picking a winner but by recovering the precise statement that contained what was true in both (§23.5's lesson) — capacity is fine now; future headroom is the open item.

Notice what Maya did not do. She didn't average Sam's optimism and Priya's pessimism into "we're cautiously sort of okay." She didn't preserve every author's wording out of politeness. She made the report read as one voice, calibrated to the actual evidence — confident where the data is strong (uptime, this quarter's load), honest where it's open (future headroom), and concrete about the one real action (fix the deploy process). The content came from three engineers; the voice came from one owner making it whole.

That is the entire job of integration: not writing the most, but making the many read as one.