Chapter 48 — Evidence dossier
Lesson map
Lesson 48 published. Map, example, EX142.
flowchart TD
N0["Learning outcomes"]
N1["48.1 Purpose"]
N2["48.2 Structure"]
N3["48.3 Linking claims"]
N4["48.4 Audience"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX142"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["48.1 Purpose"]
N2["48.2 Structure"]
N3["48.3 Linking claims"]
N4["48.4 Audience"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX142"]
[Learning outcomes]
|
v
[48.1 Purpose]
|
v
[48.2 Structure]
|
v
[48.3 Linking claims]
|
v
[48.4 Audience]
|
v
[Worked example] --> [Exercise EX142]
Learning outcomes
You will (1) assemble an evidence dossier for governed data; (2) link claims to evidence; (3) package it for assessors and regulators.
48.1 Purpose
Kofi assembles an evidence dossier for the capstone and the wider leakage governance work. The dossier must let an assessor or regulator verify claims without asking Kofi to explain. Each claim, such as that pressure data have named owners or that controls detect stuck sensors, links to evidence: ownership records, test logs, review findings, trial reports and decision records. He explains that a dossier is an argument supported by evidence, not a pile of documents. Each link is checked before the dossier is issued.
48.2 Structure
Kofi structures the dossier around the requirements: for each requirement, the claim, the controls, the evidence and the limitations. An index lets readers jump to any requirement. Evidence files are stored with dates and versions, and their integrity is recorded with hashes computed using Python's hashlib, so readers can confirm files have not changed since assembly. He also includes the independent review record and his responses, which show how the design developed. Each file's hash is listed in the index beside its title, date and version number.
48.3 Linking claims
Kofi checks every claim for evidence and finds two claims without it: that stewards were trained and that retention rules apply to pressure data. For training, he obtains attendance records. For retention, he discovers that the rule exists in policy but was never configured for pressure data, so he configures it, tests it and adds the result. He notes that assembling evidence can reveal gaps between policy and practice that nobody had noticed. Both new pieces of evidence are added to the index with their hashes.
48.4 Audience
Kofi writes a summary for non-specialists and keeps technical detail in appendices. He asks a classmate unfamiliar with the project to find evidence for three randomly chosen claims, timing the search. Each takes under five minutes. Prof. Varga notes that dossiers succeed when readers can navigate them independently, and that the discipline of evidencing every claim makes engineers more careful about what they claim in the first place. Kofi revises two index entries that slowed his classmate down, making their titles clearer and adding cross references from related requirements.
Worked example
Kofi structures a dossier by requirement with hashed evidence files, finds two unsupported claims and closes a retention configuration gap, and tests navigation with an unfamiliar classmate.
Synthetic case. The dossier is synthetic.
Errors and limits
Claims without evidence weaken the whole dossier; remove or support them.
Exercises
- EX142 — Hashing purpose. Why are evidence files hashed? Rubric: 3 = to confirm they have not changed;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX143 — Retention gap. What did the retention claim reveal? Rubric: 3 = the rule was never configured for pressure data;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX144 — Navigation test. How was navigation tested? Rubric: 3 = an unfamiliar classmate found evidence for random claims;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 48 (chapter 48 of 50)
← Chapter 47 · Course chapter index · Chapter 49 →
Continue to the next authored lesson.