Chapter 22 — Human factors and cyber policy: automation
Lesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 Safe automation"]
N2["22.2 Keeping judgement"]
N3["22.3 Monitoring automation"]
N4["Lab — Weekly automation log check"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 Safe automation"]
N2["22.2 Keeping judgement"]
N3["22.3 Monitoring automation"]
N4["Lab — Weekly automation log check"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 Safe automation]
|
v
[22.2 Keeping judgement]
|
v
[22.3 Monitoring automation]
|
v
[Lab — Weekly automation log check]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) automate routine reporting tasks safely; (2) avoid automation that removes human judgement where it is needed; (3) monitor automated steps for errors.
22.1 Safe automation
Lucas extends automation. A script produces the monthly measures automatically from the triage tool export and sends them to the practice manager. Another checks weekly that the report button exists on every computer, following the troubleshooting lesson. A third sends reminders to managers when payment holds are waiting longer than a day. Each script is small, documented and tested on synthetic data. Automation removes repetitive work, leaving people more time for tasks that need judgement and conversation. Each script has a named owner.
22.2 Keeping judgement
Lucas considers automating verdicts for all reports using a commercial scoring service. He decides against full automation: the service would mislabel some genuine supplier emails as malicious, and staff would lose trust if told a real invoice was fake. Instead, automatic verdicts apply only to exact matches with known malicious emails, while new emails are reviewed by the contractor. Deciding where people should remain in the loop is a key human factors judgement in any automation project. The contractor agrees with this approach.
22.3 Monitoring automation
Automated steps can fail silently. Lucas adds checks: each script writes a log line when it runs, and a weekly summary lists any script that did not run or produced errors. The lab simulates eight weeks of logs and finds one missed week when the button check failed because a computer was off. He adds a rule to retry the next day. Monitoring automation ensures that people know when they need to step in, rather than assuming that everything is working.
Lab — Weekly automation log check
# Weekly automation log check over eight weeks (synthetic).
scripts = ["measures", "button check", "hold reminders"]
missed = {("button check", 5)}
for w in range(1, 9):
bad = [s for s in scripts if (s, w) in missed]
if bad: print(f"week {w}: missed {bad}")
print("weeks checked: 8; missed runs:", len(missed))
Run with python3 lab_runs.py. Verified output:
week 5: missed ['button check']
weeks checked: 8; missed runs: 1
Worked example
Lucas automates measures, button checks and hold reminders, limits automatic verdicts to exact matches and monitors scripts for silent failures.
Synthetic case. Scripts and logs are synthetic.
Errors and limits
Scripts break when systems change. Logs need reading.
Exercises
- EX064 — Full automation rejected. Why reject fully automated verdicts? Rubric: 3 = mislabelled genuine emails would damage trust;; 2 = trust;; 1 = cost;; 0 = none.
- EX065 — Lab missed week. What did the lab find in eight weeks of logs? Rubric: 3 = one missed button check in week 5;; 2 = one;; 1 = vague;; 0 = none.
- EX066 — Retry rule. What rule was added after the missed run? Rubric: 3 = retry the next day;; 2 = retry;; 1 = vague;; 0 = none.
Synthesis
Automation helps when it handles routine work, keeps people where judgement matters and is itself monitored.
Continue studying — chapter 22 of 30
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →