Chapter 4 — Programming I

Chapter 4 — Programming I

Lesson map

Lesson 04 published. Map, example, EX010.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 Records as data"]
  N2["4.2 Simple checks"]
  N3["4.3 Readable code"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX010"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 Records as data"]
  N2["4.2 Simple checks"]
  N3["4.3 Readable code"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX010"]

[Learning outcomes]
    |
    v
[4.1 Records as data]
    |
    v
[4.2 Simple checks]
    |
    v
[4.3 Readable code]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX010]

Learning outcomes

You will (1) represent governance records in code; (2) write simple checks over them; (3) keep scripts readable for auditors.

4.1 Records as data

Nadia's first program reads Ardwell's list of policies as structured records: title, owner, approval date and next review date. Representing policies as data rather than prose lets a program check them. She stores the list as a CSV file and reads it with Python's standard library. Her lecturer insists on clear field names and one record per line, because governance data will be read by people who are not programmers, including internal auditors who need to understand what the script checks and why.

4.2 Simple checks

Nadia writes functions that flag policies with no owner and policies past their review date. She tests each function on a small hand-made list where she knows the right answer, including edge cases like a review due today. When a check fails, it prints the policy title and the reason, not just a count. She learns that the value of a governance script lies in actionable output: an owner can fix a specific policy, but cannot do anything with an unexplained number.

4.3 Readable code

Prof. Brenner reviews Nadia's code with an auditor's eye. Each function has a short docstring explaining the rule it enforces and where the rule comes from, such as Ardwell's policy on policies. Constants like the review interval are named, not buried as numbers. He explains that when scripts produce compliance evidence, the script itself becomes part of the evidence, so it must be understandable and version controlled. Nadia commits her code to a repository with a short history of each change.

Worked example

Nadia reads policies from CSV, flags missing owners and overdue reviews with reasons and documents rules for auditors.

Synthetic case. Policy records are synthetic.

Errors and limits

Scripts check only what is recorded. Wrong data produce confident wrong output.

Exercises

• EX010 — Policy fields. Which fields does each policy record hold? Rubric: 3 = title, owner, approval date, next review date;; 2 = four fields;; 1 = vague;; 0 = none.
• EX011 — Actionable output. Why print the policy title and reason, not just a count? Rubric: 3 = owners can act on specific items;; 2 = actionable;; 1 = vague;; 0 = none.
• EX012 — Script as evidence. Why must compliance scripts be readable and versioned? Rubric: 3 = the script becomes part of the evidence;; 2 = evidence;; 1 = vague;; 0 = none.

Synthesis

Simple, readable scripts make governance records checkable and their output actionable.

Continue studying — chapter 04 of 50

← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →