Chapter 5 — Engineering communication | Engineering Threat intelligence and OSINT

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, EX013.

flowchart TD
  N0["Learning outcomes"]
  N1["5.1 Writing for the reader's decision"]
  N2["5.2 Fact, assumption, judgment"]
  N3["5.3 TLP on documents"]
  N4["5.4 Figures"]
  N5["5.5 Review"]
  N6["Practice note — Short forms"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX013"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["5.1 Writing for the reader's decision"]
  N2["5.2 Fact, assumption, judgment"]
  N3["5.3 TLP on documents"]
  N4["5.4 Figures"]
  N5["5.5 Review"]
  N6["Practice note — Short forms"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX013"]

[Learning outcomes]
    |
    v
[5.1 Writing for the reader's decision]
    |
    v
[5.2 Fact, assumption, judgment]
    |
    v
[5.3 TLP on documents]
    |
    v
[5.4 Figures]
    |
    v
[5.5 Review]
    |
    v
[Practice note — Short forms]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX013]

Learning outcomes

You will (1) write requirements, design notes and incident summaries in plain English; (2) separate facts, assumptions and judgments as ICD 203 recommends; (3) apply TLP labels to engineering documents; (4) choose figures that reduce rather than add confusion.

5.1 Writing for the reader's decision

Every document answers a reader's question. A requirement answers "what must the system do?" A design note answers "why this way?" An intelligence summary answers "what should I do now?" Start with the answer, then support it.

An analyst reading a summary at the start of a shift wants to know whether to block, watch or ignore. If that answer is buried in the fourth paragraph, the reader may act on the wrong one. Kofi puts the recommended action in the first sentence and the evidence below it, so a reader who stops early still acts correctly and one who reads on can check the reasoning.

5.2 Fact, assumption, judgment

"Partner A's feed delivered 12,000 indicators yesterday" is a fact. "Partner A's feed is mostly current" is an assumption unless measured. "We should prioritise Partner A for automated blocking" is a judgment. ICD 203's tradecraft standards ask writers to distinguish information from assumptions and judgments; engineers benefit from the same discipline.

Kofi marks each kind in his drafts. A fact carries its source and date, an assumption says what would confirm it, and a judgment states who made it. Readers can then challenge the right thing.

5.3 TLP on documents

A design note that contains partner names under an AMBER sharing agreement inherits that restriction. Put the TLP 2.0 label in the header and footer. Untagged documents tend to spread.

Kofi's template puts the label in both places so that a printed page still shows it. A document that mixes material should carry the most restrictive label among its parts, or be split so the wider part can travel further. Partner names are often the restricted element, and replacing them with a neutral identifier may let the rest be shared.

5.4 Figures

A single chart of time-to-block by source is clearer than a dashboard of twenty gauges. Label axes with units; state the period and the data source in the caption.

Kofi tested a dashboard of many gauges on the night shift and found nobody could say which source was slowest. A single bar chart sorted by median time to block answered that in seconds. Each chart he publishes now has a caption giving the period, the source of the data and the unit, so a reader can judge whether a change is real or a result of a different measurement.

5.5 Review

Ask a reviewer to state your main point back in one sentence. If they cannot, rewrite.

Kofi tries this with a colleague before sending any design note. When the colleague described his note on enrichment as being about logging, he found the conclusion was in the last paragraph. Moving it to the top fixed the problem. A second check is to ask what action the reader should take; if the reviewer cannot say, the note lacks a clear request. Both checks take a few minutes and spare readers a confusing document.

Practice note — Short forms

Executives read the first paragraph and the figure. Analysts read the indicator table. Engineers read the decision record. Kofi writes each document with a three-line summary at the top — decision, reason, deadline — so every reader can stop early without missing the action they own.

Worked example

Kofi drafts a note recommending a second enrichment worker. The first draft opens with three paragraphs of history. He rewrites: "Add one enrichment worker before 1 March; queue delay exceeded 10 minutes on 9 of 30 days (fact). We assume volume grows 20% this year (assumption)." The manager approves in one reading.

Synthetic case. The note and figures are invented.

Errors and limits

Over-labelling everything RED stops necessary sharing; under-labelling leaks. Plain language is not the same as vague language.

Exercises

EX013 — Label sentences. Classify "the queue exceeded 10 minutes on 9 of 30 days" and "volume will grow 20%". Rubric: 3 = fact; assumption (or forecast judgment); 2 = one right; 1 = both facts; 0 = none.
EX014 — Inherited label. A design note quotes partner names covered by an AMBER agreement. What TLP label should the note carry? Rubric: 3 = at least TLP:AMBER (inherits); 2 = some label; 1 = CLEAR; 0 = none.
EX015 — Caption contents. List three things a chart caption should state. Rubric: 3 = units/metric, period, data source; 2 = two; 1 = title only; 0 = none.

Synthesis

Answer first, separate fact from assumption and judgment, label sensitivity, and make each figure carry its units and source.

Continue studying — chapter 05 of 50

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