Appendix B — Document Templates

Ready-to-use skeletons for the book's major document types. Copy one, fill the [brackets], delete the guidance notes, and you have a first draft with the right bones.

A template is scaffolding, not a straitjacket. It gives you the structure the genre expects so you can spend your thinking on the content, not the shape. Two rules before you use any of these: (1) lead with what the reader most needs — most of these put the conclusion or the ask near the top, because readers scan (Chapter 4); and (2) delete every bracket and every italic note before you send. A template that ships with [insert problem here] still in it is the most embarrassing error in this appendix.

The relevant chapter is named on each template. Go there for the why; this appendix is the what.

1. Lab / scientific report — IMRaD (Chapter 13)

Title: [Names the system and the finding — informative, not "Lab 3"]
Abstract [150–250 words, written LAST]: [Purpose. What you did.
  The actual key result WITH NUMBERS. What it means. One sentence each.]

1. Introduction   [Why did you do this?]
   - Context → the gap → what this study does. Purpose in para 1.
2. Methods        [What did you do? — replicable by a peer, no questions]
   - Every parameter that changes the result. Passive voice OK here.
3. Results        [What did you find? — observation only, no judgment]
   - Measurements stated neutrally. No "excellent," "proves," "as expected."
   - Figures/tables carry the data; prose points to them.
4. Discussion     [What does it mean? — interpret, don't restate]
   - Make sense of it · relate to prior work · BOUND the claim · limitations.
References: [uniform style — Appendix C]

Write the sections out of order: Methods first (most mechanical), Abstract last (you can't summarize what isn't finished). The genre's whole discipline lives in the Results/Discussion boundary — keep observation and interpretation in separate rooms. Most common failure: a judgment word ("excellent," "as expected," "proves") leaking into Results.

2. Technical report — workplace / decision (Chapter 13, Chapter 21)

Title: [The subject and the bottom line]
Executive Summary [stands alone — a busy reader decides from this alone]:
  - Recommendation: [the one thing you want decided]
  - Why (key reasons): [2–3, with a number each]
  - Action needed: [what, by whom, by when]

1. Background       [the problem, briefly — why this report exists]
2. Findings         [scannable: a short list or small table]
3. Recommendation   [restate, with the reasoning]
4. Next steps        [owner + date]
Appendix: Methodology  [keep it — someone will check — but demote it here]

3. Research-paper abstract (Chapter 14)

[Background — 1–2 sentences: the field and the gap.]
[Objective — 1 sentence: what THIS paper does. "Here we…"]
[Methods — 1–2 sentences: the approach, briefly.]
[Results — 2–3 sentences: the actual findings, with numbers.]
[Conclusion — 1 sentence: what it means / why it matters.]

Structured-abstract variant: use the literal labels Background / Methods / Results / Conclusions if the venue requires them.

4. Proposal / business case (Chapter 20)

Executive Summary [half a page, stands alone]:
  [Situation → recommendation → justification (a number) → cost/catch
   → dated ask.]

1. Problem / Opportunity   [quantify the pain; make the reader feel it]
2. Proposed Solution       [what you'll do — clearly answers the problem]
3. Approach / Plan         [how, with milestones and timeline]
4. Cost & ROI              [investment, expected return, payback, the catch]
5. Risks & Alternatives    [including "do nothing" — and why not]
6. The Ask                 [one dated, specific request]

Write the executive summary first and hardest, not last and fastest — for the decision-maker it often is the whole document. Most common failure: a vivid solution attached to a problem the reader never feels. Quantify the pain before you pitch the fix.

5. Executive summary (standalone — Chapter 20, Chapter 37)

[Recommendation — the decision you want, first sentence.]
[Situation — one sentence of why this is on their desk.]
[Justification — the 2–3 strongest reasons, each with a number.]
[Cost / risk — the honest catch.]
[Next step — what happens now, who owns it, by when.]

Test: strip everything else away — can the reader still decide, and do they know the ask?

6. Professional emails (Chapter 19)

Request

Subject: [Action + deadline — "Approval needed by Thu: vendor contract"]
Hi [Name],
[The ask, in sentence one: what you need and by when.]
[One short paragraph of only the context they need to say yes.]
[What you'll do / what's attached. One clear next step.]
Thanks, [You]

Bad news

Subject: [Honest, specific — not cheery, not cryptic]
Hi [Name],
[Brief warm opening — one line, no fake buildup.]
[The bad news, stated plainly and early. Don't bury it; don't pad it.]
[The why, briefly — and what you're doing about it / the options.]
[The path forward + your offer to help.]
Best, [You]

Saying no

Subject: Re: [their request]
Hi [Name],
[Thank them / acknowledge the request — one line.]
[The no, clearly. "I won't be able to take this on." No maybe-ish fog.]
[One honest reason (optional) — not a defensive paragraph.]
[An alternative if you have one: another person, time, or scope.]
Best, [You]

Pick the right channel before you draft: email for anything that needs a record or crosses time zones; a call or chat for anything emotional, urgent, or likely to bounce back and forth. The subject line is the most-read part of any email — spend a moment on it. For bad news and refusals, the kindest thing is clarity: a hedged "no" that the reader mistakes for "maybe" wastes everyone's time and erodes trust.

7. Status / progress report (Chapter 21)

Project: [name]   Period: [dates]   Overall: [🟢 / 🟡 / 🔴]

Headline: [one line — on track, or the one thing needing attention.]

Done this period:   [outcomes, not activities — "shipped X," not "worked on X"]
Next period:        [what's planned]
Blockers / needs:   [what you need, from whom, by when — or "none"]
Risks (exceptions):  [only items off-track; compress the routine to a line]

8. Incident report (Chapter 21, Chapter 34)

Title: [System] incident — [date], [one-line impact]
Severity: [SEV level]   Duration: [start–end]   Status: [resolved / monitoring]

Summary:          [what happened and the impact, in 2–3 sentences. BLUF.]
Timeline:         [neutral, timestamped facts — what happened, not why]
  HH:MM  [event]
Root cause:       [why — system framing: "the pipeline allowed…," not "X erred"]
Impact:           [who/what was affected, quantified]
Corrective actions: [table — Action | Owner | Due date]

9. Meeting minutes (Chapter 21)

Meeting: [topic]   Date: [date]   Attendees: [names]

Decisions:   [what was decided — outcomes, not a transcript]
Action items:
  | Action | Owner | Due |
Open questions / parked: [unresolved items]
Next meeting: [date, if set]

10. README (Chapter 25)

# [Project name]
[One sentence: what this is and what problem it solves.]

[badges: build | version | license]

## Features
- [Concrete capabilities — not adjectives like "powerful," "flexible"]

## Install
```[exact, copy-pasteable command(s)]```

## Quick start
```[minimal runnable example — the call AND the result]```
[One line: link to fuller docs.]

## Documentation / Usage   [link or short section]
## Contributing            [link to CONTRIBUTING]
## License                 [name]

Lead with quick-start; move philosophy down. The metric is time-to-first-success — how fast a stranger gets a working result. Run the clean-machine test: clone the project somewhere fresh and follow your own install steps with literal, stupid obedience. Every place you have to improvise is a gap your reader will hit. Most common failure: a wall of "what is date parsing, philosophically" where the install command should be.

11. API endpoint reference (Chapter 25)

### [METHOD] /path/to/resource
[One sentence: what this endpoint does.]

Request
  | Field | Type | Required | Description |
  [Every field, typed, required-marked.]

Example request:  ```[curl or code, copy-pasteable]```

Response (200)
  ```[real JSON example]```
  | Field | Type | Description |

Errors
  | Status | Error code | Meaning |
  [The part everyone skips and integrators need most.]

12. Architecture Decision Record — ADR (Chapter 25, Chapter 34)

# ADR-[NNN]: [short decision title]
Status: [Proposed | Accepted | Superseded by ADR-XXX]   Date: [date]

## Context
[What forces a decision now? What constraints and options were weighed?]

## Decision
[The choice, stated plainly. "We will…"]

## Consequences
[The trade-offs accepted — the good AND the costs. What gets harder.]

Numbered, append-only: to change a decision, write a new ADR that supersedes this one — don't edit history.

13. Data memo (Chapter 27)

To: [decision-maker]   From: [you]   Re: [the question this answers]

Recommendation: [what they should DO — first, before the analysis.]

Key findings:
  - [Finding 1 — with the number — and its implication ("so what?")]
  - [Finding 2 …]
  [Figure with an INTERPRETIVE caption — states the takeaway, not "Figure 1"]

Method (brief): [one paragraph — enough to trust it; details in appendix]
Caveats: [limits that would change the decision — kept, not hidden]

The order is the whole point: recommendation-first beats findings-first beats methodology-first for a busy decision-maker. Run the "so what?" test on every finding — a number with no implication is data, not a memo. Captions interpret; they don't label (Chapter 9). Most common failure: leading with how you did the analysis instead of what the reader should do about it.

14. Clinical note — SOAP (Chapter 36)

⚠️ Educational template only; not medical advice. Follow your institution's documentation standards.

S (Subjective): [what the patient reports — in their words / history]
O (Objective):  [what you measured — vitals, exam, labs, WITH NUMBERS.
                 No conclusions here — measurement only.]
A (Assessment): [your clinical impression — WITH its uncertainty shown
                 (differential, degree of confidence)]
P (Plan):       [what you'll do — tests, treatment, follow-up, and a
                 NAMED escalation threshold ("return if temp > X")]

15. Patient instruction (Chapter 36)

⚠️ Educational template only; not medical advice.

[Plain-language title — 6th–8th-grade level]
What to do:       [concrete actions — "drink 8 glasses of water," not
                   "maintain hydration." Dose, frequency, route, timing.]
                  [If medication: maximum in 24 hours, stated explicitly.]
How you'll know it's working: [the sign of improvement to watch for]
When to call for help:        [the escalation trigger — the most-skipped,
                               most-important line. Specific symptoms +
                               who to call.]

16. One-pager / policy brief (Chapter 37)

[Title — names the issue and signals the recommendation]

Recommendation: [one clear recommendation, at the top.]
Why it matters: [2–3 numbers that quantify the stakes.]
The evidence:   [the single strongest supporting point.]
The cost / risk: [the honest catch — and why the upside wins.]
Next step:      [the specific, dated action you're asking for.]
[Everything else is demoted or cut. Must survive a 60-second read.]

A note on adapting templates

These are starting points, not laws. A detailed test report sits near the academic IMRaD end; a recommendation memo sits at the far workplace end (Chapter 13) — read your specific reader and shift accordingly. When your field or organization publishes its own template, that one wins (Chapter 23, Appendix F): house style overrides this appendix for internal work. And whatever you copy, run it through Appendix A before it goes out — a well-structured document full of bloat and dangling modifiers still fails.