Chapter 9 — Evidence and measurement
Lesson map
Lesson 09 published. Map, example, EX025.
flowchart TD
N0["Learning outcomes"]
N1["9.1 Choosing measures"]
N2["9.2 Collecting evidence reliably"]
N3["9.3 Reporting clearly"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX025"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["9.1 Choosing measures"]
N2["9.2 Collecting evidence reliably"]
N3["9.3 Reporting clearly"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX025"]
[Learning outcomes]
|
v
[9.1 Choosing measures]
|
v
[9.2 Collecting evidence reliably]
|
v
[9.3 Reporting clearly]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX025]
Learning outcomes
You will (1) choose measures that inform decisions; (2) collect evidence reliably; (3) report results clearly.
9.1 Choosing measures
Lucas chooses measures with the manager: percentage of credit grants matched to recorded workshops, number of node sync alerts per month, time to restore a node from backup, and number of privileged ledger actions without an approved change ticket. Each has a target. He avoids counting things just because they are easy, such as total transactions, unless they help a decision. A good measure tells someone what to do next, such as investigating an unmatched grant or fixing a slow restore, and can be explained in one plain sentence to staff and members.
9.2 Collecting evidence reliably
Lucas collects evidence directly from systems: ledger data from a node, booking data from the database's read-only account and restore times from timed drills. He records the source, time and method for each, and stores a SHA-256 hash of each export so later changes can be detected. He writes the steps down so another technologist can repeat them. Reliable evidence is repeatable and traceable. Evidence that relies on memory or screenshots is easily disputed, and decisions made on it may be wrong without anyone being able to tell.
9.3 Reporting clearly
Lucas's first monthly report shows 412 of 415 credit grants matched to workshops, with the three unmatched explained as late records later confirmed. Restore time was 38 minutes against a 60-minute target. One privileged action lacked a ticket and is under review. He shows counts, not just percentages, and explains each exception in plain words. The manager appreciates the clarity. Clear reports build trust and make problems visible early. Ms Adebayo reminds him that a report which hides problems is worse than no report, because it gives false confidence.
Worked example
Lucas reports 412 of 415 grants matched, a 38-minute restore against 60, and one privileged action without a ticket under review.
Synthetic case. The measures and results are synthetic.
Errors and limits
Counting easy things, like total transactions, rarely informs any decision.
Exercises
- EX025 — Measure list. Name one of Lucas's measures. Rubric: 3 = time to restore a node;; 2 = grants matched;; 1 = total transactions;; 0 = none.
- EX026 — Export integrity. How are export changes made detectable? Rubric: 3 = storing a SHA-256 hash of each export;; 2 = hashing;; 1 = screenshots;; 0 = none.
- EX027 — Restore result. What restore time was measured? Rubric: 3 = 38 minutes against 60;; 2 = 38 minutes;; 1 = 2 hours;; 0 = none.
Synthesis
Decision-focused measures and reliable, clear reporting make evidence useful.
Continue studying — chapter 09 of 30
← Chapter 08 (draft) · Course chapter index · Chapter 10 (draft) →