◇ OpenCyber Academy
Engineering · Chapter 35 · English

Chapter 35 — Design studio II

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 35 — Design studio II

Lesson map

Lesson 35 published. Map, example, EX103.

flowchart TD
  N0["Learning outcomes"]
  N1["35.1 The new source"]
  N2["35.2 Reusing components"]
  N3["35.3 Privacy questions"]
  N4["35.4 Defending the design"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX103"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["35.1 The new source"]
  N2["35.2 Reusing components"]
  N3["35.3 Privacy questions"]
  N4["35.4 Defending the design"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX103"]

[Learning outcomes]
    |
    v
[35.1 The new source]
    |
    v
[35.2 Reusing components]
    |
    v
[35.3 Privacy questions]
    |
    v
[35.4 Defending the design]
    |
    v
[Worked example] --> [Exercise EX103]

Learning outcomes

You will (1) design governance for a new data source; (2) apply lessons from the first studio; (3) defend the design under questioning.

35.1 The new source

The second design studio introduces a new data source: acoustic loggers that listen for leaks on pipes and send daily noise summaries. Tidewater plans to install two thousand loggers. Kofi must design governance for the logger data, including owners, rules, lineage into the leakage process, privacy considerations and retention. The brief requires the design to reuse existing components where possible and to justify any new ones, reflecting the lesson that governance should scale without rebuilding everything. The installation is planned over two years.

35.2 Reusing components

Kofi reuses the rule library for range and completeness checks, the catalogue for metadata, the change notice process for the vendor interface and the reconciliation pattern to compare logger alerts with confirmed leaks found by repair crews. He adds one new component: a model card describing how the vendor's algorithm turns noise into leak probability, including its known false positive rate. He explains that algorithmic outputs need their own documentation because their quality depends on training data users cannot see. The vendor supplies the rate.

35.3 Privacy questions

Loggers placed on pipes outside homes might capture sounds beyond pipe noise. Kofi checks the vendor specification and confirms the device records only frequency summaries, not audio. He records this in the data protection assessment and requires the vendor to notify any change that would capture audio. The panel questions whether summaries could reveal household activity patterns. He concedes the possibility for loggers near single homes and proposes aggregating daily summaries before analysts see them. The panel accepts this proposal with a review clause.

35.4 Defending the design

The panel tests Kofi's design with scenarios: a firmware update increases false positives, loggers in one district stop reporting and a journalist asks whether Tidewater listens to homes. He answers each using the components and records in his design. The panel notes improvement over the first studio, particularly in anticipating failure and people's concerns. Prof. Varga comments that the best designs show their reasoning, so reviewers can test them rather than simply trust the designer. The panel approves the design with minor wording changes requested.

Worked example

Kofi designs governance for acoustic loggers by reusing rules, catalogue, notices and reconciliation, adds a model card, addresses privacy with summaries and aggregation and defends the design under scenarios.

Synthetic case. The loggers are synthetic.

Errors and limits

Vendor assurances need verification; check specifications.

Exercises

Continue studying — lesson 35 (chapter 35 of 50)

← Chapter 34 · Course chapter index · Chapter 36 →

Continue to the next authored lesson.