Chapter 29 — Capstone build

Chapter 29 — Capstone build

Lesson map

Lesson 29 published. Map, example, EX085.

flowchart TD
  N0["Learning outcomes"]
  N1["29.1 Toolkit"]
  N2["29.2 Documentation"]
  N3["29.3 Testing"]
  N4["29.4 Handover"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX085"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["29.1 Toolkit"]
  N2["29.2 Documentation"]
  N3["29.3 Testing"]
  N4["29.4 Handover"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX085"]

[Learning outcomes]
    |
    v
[29.1 Toolkit]
    |
    v
[29.2 Documentation]
    |
    v
[29.3 Testing]
    |
    v
[29.4 Handover]
    |
    v
[Worked example] --> [Exercise EX085]

Learning outcomes

You will (1) build a privacy toolkit; (2) combine labs; (3) document it.

29.1 Toolkit

Aisha combines flows, access request, scan, CCTV and inactive account scripts into a toolkit. The scripts come from earlier labs: the SDK flow review, the access request coverage check, the file scanner, the CCTV retention check and the inactive account job. She gives them a common structure, consistent output formats and a shared configuration file for thresholds, so the privacy team can run them the same way each time. Thresholds such as thirty days for footage and two years for inactive accounts live in the configuration file, not in the code.

29.2 Documentation

Each script has a purpose, inputs, outputs and limits. For the scanner, the limits section says clearly that free-text health information is not detected. For the CCTV check, it says that the script reads an index, not footage. Documentation also explains how to change thresholds and where outputs are stored. Aisha writes it for people who did not attend her course. Each limits section is written as a direct warning, for example: a clean scan result does not mean a file contains no health information. A worked example with synthetic files shows the expected output for each script.

29.3 Testing

She tests all with synthetic data. Each script has a set of synthetic input files with known correct results, so anyone can confirm that the script still works after changes. The tests include edge cases such as empty files, missing dates and accounts with both debt and inactivity. All tests pass before handover, and the results are saved with the toolkit. One test feeds the deletion job an account that is both inactive and in debt and confirms that the hold wins over deletion.

29.4 Handover

The toolkit is handed to Quayside's privacy team. Mr. Reilly notes that tools must be maintained. The privacy team names an owner for the toolkit and agrees to review it each year. Aisha explains that scripts written for one version of a system may break when systems change. She also reminds the team that the toolkit uses only standard Python libraries, which keeps maintenance simple and avoids extra dependencies. The privacy team runs every script once with Aisha watching. The first annual review date is set.

Worked example

Aisha builds and documents a five-script toolkit tested on synthetic data.

Synthetic case. The toolkit is synthetic.

Errors and limits

Tools need owners.

Exercises

• EX085 — Scripts. How many scripts are combined? Rubric: 3 = five;; 2 = partly correct;; 1 = wrong;; 0 = none.
• EX086 — Docs. What does each script's documentation include? Rubric: 3 = purpose, inputs, outputs, limits;; 2 = most;; 1 = one;; 0 = none.
• EX087 — Data. What data are used for testing? Rubric: 3 = synthetic;; 2 = partly correct;; 1 = real;; 0 = none.

Continue studying — lesson 29 (chapter 29 of 30)

← Chapter 28 · Course chapter index · Chapter 30 →

Continue to the next authored lesson.