Chapter 38 — Capstone implementation

Chapter 38 — Capstone implementation

Lesson map

Lesson 38 published. Map, example, EX112.

flowchart TD
  N0["Learning outcomes"]
  N1["38.1 Building the monitor"]
  N2["38.2 Testing with seeded data"]
  N3["38.3 Documenting operation"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX112"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["38.1 Building the monitor"]
  N2["38.2 Testing with seeded data"]
  N3["38.3 Documenting operation"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX112"]

[Learning outcomes]
    |
    v
[38.1 Building the monitor]
    |
    v
[38.2 Testing with seeded data]
    |
    v
[38.3 Documenting operation]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX112]

Learning outcomes

You will (1) implement a read-only monitoring service; (2) test it with seeded data; (3) document operation for volunteers.

38.1 Building the monitor

Sofia implements the monitor as a small Python program using only the standard library. Every hour it reads new ledger events from a validator through a read-only interface, reads approved shifts from the reporting database, recomputes balances by replaying events, checks the invariants, and compares issuance with approved shifts. It also lists any privileged action, such as a role change or pause. Results are written to a dated log, and alerts are sent by email to the duty volunteer. The code is reviewed by a classmate and by the cooperative's developer before use.

38.2 Testing with seeded data

Sofia prepares synthetic datasets with seeded problems: a missing issuance event, a balance mismatch, an issuance without an approved shift, an unexpected role change and a duplicated batch. The monitor detects all five and alerts within six minutes of each hourly run. She also runs it on a clean month of data, where it raises no alerts. A first version raised a false alarm when a shift was approved after midnight; she fixed the date logic and reran all tests. Seeded testing gives clear evidence that the monitor detects what it should.

38.3 Documenting operation

Sofia writes a two-page guide for volunteers: what the monitor checks, what each alert means, the first steps for each, and who to contact. Each alert type links to the relevant part of the incident plan. She also documents how to restart the monitor, where logs are kept and how to update the list of privileged functions. A volunteer with no programming background follows the guide successfully during a trial. Documentation makes the service maintainable after Sofia graduates, which the board had specifically asked for when approving her capstone.

Worked example

The monitor detects all five seeded problems within six minutes, raises no alerts on a clean month, and a fixed midnight date bug removes a false alarm.

Synthetic case. The monitor, datasets and trial are synthetic.

Errors and limits

Testing only with clean data cannot show whether a monitor detects real problems.

Exercises

• EX112 — Seeded problems. How many seeded problems did the monitor detect? Rubric: 3 = all five;; 2 = five;; 1 = three;; 0 = none.
• EX113 — False alarm cause. What caused the early false alarm? Rubric: 3 = a shift approved after midnight;; 2 = date logic;; 1 = network;; 0 = none.
• EX114 — Guide test. Who successfully followed the guide? Rubric: 3 = a volunteer without programming background;; 2 = a volunteer;; 1 = only Sofia;; 0 = none.

Synthesis

A reviewed, seeded-tested and documented monitor can outlast its builder.

Continue studying — chapter 38 of 40

← Chapter 37 (draft) · Course chapter index · Chapter 39 (draft) →