Chapter 17 — Control and feedback basics

Chapter 17 — Control and feedback basics

Lesson map

Lesson 17 published. Map, example, EX049.

flowchart TD
  N0["Learning outcomes"]
  N1["17.1 Feedback loops"]
  N2["17.2 Monitoring as feedback"]
  N3["17.3 Safe automatic responses"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX049"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["17.1 Feedback loops"]
  N2["17.2 Monitoring as feedback"]
  N3["17.3 Safe automatic responses"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX049"]

[Learning outcomes]
    |
    v
[17.1 Feedback loops]
    |
    v
[17.2 Monitoring as feedback]
    |
    v
[17.3 Safe automatic responses]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX049]

Learning outcomes

You will (1) describe feedback loops; (2) relate them to monitoring and response; (3) design safe automatic responses.

17.1 Feedback loops

Control theory studies systems that measure output and adjust input to reach a goal. A thermostat measures temperature and switches heating. Jonas sees a parallel in security operations: monitoring measures system behaviour, compares it with expected behaviour and triggers a response. Like any control loop, monitoring has delay, noise and the risk of overreacting. Understanding feedback helps him design responses that stabilise the system rather than causing new problems. He sketches the loop for the token platform, labelling the sensor, the comparison, the controller and the actuator, so that each part can be examined for delay and error.

17.2 Monitoring as feedback

For the token platform, Jonas defines measured signals: minting per hour, transfers per hour, queued administrative actions and node health. Each signal has a set point or range and an alert threshold. When minting exceeds the capacity bound, the loop should respond. He considers delays: an alert that takes a day to reach a human is too slow for a problem that grows each hour. The EthTrust specification notes that monitoring can enable rapid response but that automated responses can also be triggered deliberately to cause disruption.

17.3 Safe automatic responses

Jonas designs a limited automatic response: if minting exceeds the cap, the gateway stops submitting new minting requests and alerts staff, but the contract itself is not paused automatically, because pausing affects all members. A pause requires a multi-signature decision by two board members within a documented procedure. This balances speed with caution. Feedback design teaches that the safest automatic responses are narrow and reversible, with broader actions left to humans who can judge context. The procedure is written into the runbook and tested.

Worked example

Jonas defines four monitored signals and an automatic gateway stop for excess minting, while contract pauses require a two-person decision.

Synthetic case. Signals and procedures are synthetic; EEA EthTrust is a real source.

Errors and limits

Automatically pausing an entire contract on any alert lets false alarms, or deliberate triggers, disrupt all members.

Exercises

• EX049 — Control parallel. What does monitoring parallel in control theory? Rubric: 3 = a feedback loop;; 2 = loop;; 1 = open loop;; 0 = none.
• EX050 — Automatic action. What happens automatically on excess minting? Rubric: 3 = gateway stops minting requests and alerts staff;; 2 = gateway stop;; 1 = contract paused;; 0 = none.
• EX051 — Pause decision. Who decides a contract pause? Rubric: 3 = two board members via multisig;; 2 = two people;; 1 = script;; 0 = none.

Synthesis

Monitoring is a feedback loop; safe responses are narrow, fast and reversible, with broad actions left to people.

Continue studying — chapter 17 of 50

← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →