◇ OpenCyber Academy
Engineering · Chapter 5 · English

Chapter 5 — Engineering communication

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 5 — Engineering communication

Lesson map

Lesson 05 published. Map, example, EX009.

flowchart TD
  N0["Learning outcomes"]
  N1["5.1 The decision memo"]
  N2["5.2 Communicating uncertainty"]
  N3["5.3 Diagrams"]
  N4["5.4 Audiences"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX009"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["5.1 The decision memo"]
  N2["5.2 Communicating uncertainty"]
  N3["5.3 Diagrams"]
  N4["5.4 Audiences"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX009"]

[Learning outcomes]
    |
    v
[5.1 The decision memo]
    |
    v
[5.2 Communicating uncertainty]
    |
    v
[5.3 Diagrams]
    |
    v
[5.4 Audiences]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX009]

Learning outcomes

You will (1) write a decision memo that separates facts, assumptions and recommendations; (2) present uncertainty about quantum timelines honestly; (3) draw architecture diagrams with text alternatives; and (4) adapt a message for technical and executive audiences. It builds on Chapters 1–4 and is used in every design review later.

5.1 The decision memo

A memo opens with the decision requested, then gives context, options, recommendation, risks and what would change the recommendation. In PQC work, label four kinds of statement: fact ("FIPS 203 was published in August 2024"), assumption ("we plan as if a cryptographically relevant quantum computer could exist within 15 years"), estimate ("migration of the VPN will take nine months") and recommendation. Mixing them is how timelines become myths.

Labelling each statement lets readers challenge the right thing. A fact can be checked against its source; an assumption can be varied to see whether the recommendation still holds; an estimate can be compared with actual progress later. When a sentence mixes them, such as a migration date presented as certain, nobody can tell which part to question.

5.2 Communicating uncertainty

Never give a single "Q-Day". State a range of assumptions and show which decisions are robust across it. Mosca's inequality — if data lifetime plus migration time exceeds time-to-quantum, act now (Mosca 2018) — is useful precisely because it can be evaluated across a range. A recommendation that holds for all plausible ranges is easy to defend.

In practice, the memo shows a small table: rows for assumed time-to-quantum, columns for data lifetime and migration time, and cells marking where action is needed. If every cell says act, the debate about the exact year becomes irrelevant. If the answer flips within the plausible range, the memo says so and explains what new evidence would settle it.

5.3 Diagrams

Architecture diagrams show components, trust boundaries and where each cryptographic function happens: key exchange, signature, data at rest. Every diagram needs a text alternative describing the same content for accessibility and for review; reviewers often find errors when forced to read the text version.

Marking where each cryptographic function happens shows the migration scope at a glance: every key exchange and signature arrow is a candidate for change, while symmetric encryption at rest may only need larger keys. The text version lists each arrow with its algorithm and owner. Reviewers reading that list often spot a hidden dependency, such as a signature used inside a firmware update path that the diagram drew as a single box.

5.4 Audiences

For engineers: algorithms, parameter sets, protocols, test evidence. For executives: risk, cost, schedule, what is protected and what is not. For auditors: requirement traceability and evidence. The same facts, differently ordered.

An engineer reading the executive version may think detail is missing, and an executive reading the engineering version may miss the decision. Writing separate versions from one source of facts keeps them consistent. Auditors need a third ordering: each requirement, the evidence that it is met, and where that evidence is stored. BPA keeps all three versions in one repository so a changed fact updates every audience together.

5.5 Worked example: BPA's one-page memo

Decision requested: fund a 12-month cryptographic inventory and a hybrid TLS pilot. Facts: standards exist; customs records must remain confidential for 25 years. Assumption: time-to-quantum swept from 10 to 30 years. Finding: for 25-year records, any time-to-quantum below about 26 years (25 years of confidentiality plus roughly 9 months of migration) means today's recorded traffic is at risk — so the decision is robust across the whole 10–30-year sweep except its optimistic tail, and the tail does not change the action. Not claimed: any date. Risks: middlebox incompatibility, vendor delay.

5.6 Common errors and limits

A single date invites argument about the date instead of the decision, and it becomes wrong as soon as estimates move. A diagram without text excludes readers using screen readers and hides errors that writing would expose. A buried decision means executives leave the meeting without making it. Each of these is easy to fix before the memo is sent.

Exercises

Synthesis

Good engineering communication labels facts, assumptions, estimates and recommendations, expresses timelines as ranges, gives diagrams text alternatives and orders the same facts for each audience.

Continue studying — chapter 05 of 50

← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →