Chapter 10 — Engineering ethics and safety

Chapter 10 — Engineering ethics and safety

Lesson map

Lesson 10 published. Map, example, EX028.

flowchart TD
  N0["Learning outcomes"]
  N1["10.1 Duties of engineers"]
  N2["10.2 Who could be harmed"]
  N3["10.3 Project safety principles"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX028"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["10.1 Duties of engineers"]
  N2["10.2 Who could be harmed"]
  N3["10.3 Project safety principles"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX028"]

[Learning outcomes]
    |
    v
[10.1 Duties of engineers]
    |
    v
[10.2 Who could be harmed]
    |
    v
[10.3 Project safety principles]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX028]

Learning outcomes

You will (1) apply engineering ethics to financial systems; (2) consider members who could be harmed; (3) set safety principles for the project.

10.1 Duties of engineers

Engineering codes of ethics ask practitioners to hold paramount the safety and welfare of the public, to act within their competence and to be honest about limits. Jonas applies these to the cooperative: members rely on credits to reduce energy bills, some are elderly or on low incomes, and errors could cost them money or trust. He writes that his duty includes refusing to deploy code he has not adequately tested, and telling the board plainly when a risk remains, even if that delays the project.

10.2 Who could be harmed

Jonas lists stakeholders: members who earn and spend credits; members without smartphones who rely on statements; the board, legally responsible for funds; node operators; and the local utility. For each he notes possible harms: lost credits from bugs, privacy loss if household generation patterns are published, exclusion if the system is hard to use, and liability for the board. Thinking about harm by stakeholder helps him design protections, such as keeping household readings off the shared ledger and providing paper statements on request.

10.3 Project safety principles

Jonas and Dr Nwosu agree principles for the project: work only on test networks and synthetic data until approved; never handle members' private keys; disclose any discovered weakness privately to the responsible party; and never publish details that could help someone take credits that are not theirs. The board adopts these principles. Written principles guide decisions when deadlines press, and make clear to everyone that security work on financial systems is done defensively and with permission. Dr Nwosu reviews them each year with the board.

Worked example

Jonas lists five stakeholder groups and their harms; the board adopts four safety principles for the project.

Synthetic case. Stakeholders and principles are synthetic.

Errors and limits

Deploying untested code under deadline pressure puts members' money at risk.

Exercises

• EX028 — Paramount duty. What do codes ask engineers to hold paramount? Rubric: 3 = safety and welfare of the public;; 2 = public welfare;; 1 = profit;; 0 = none.
• EX029 — Privacy protection. How are household patterns protected? Rubric: 3 = readings kept off the shared ledger;; 2 = off-chain;; 1 = published;; 0 = none.
• EX030 — Safety principle. Name one project safety principle. Rubric: 3 = never handle members' private keys;; 2 = test networks only;; 1 = vague;; 0 = none.

Synthesis

Ethical duties and written safety principles keep financial-system engineering focused on members' welfare.

Continue studying — chapter 10 of 50

← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →