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 Delay and stability"]
N3["17.3 Root causes"]
N4["17.4 Measuring the loop"]
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 Delay and stability"]
N3["17.3 Root causes"]
N4["17.4 Measuring the loop"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX049"]
[Learning outcomes]
|
v
[17.1 Feedback loops]
|
v
[17.2 Delay and stability]
|
v
[17.3 Root causes]
|
v
[17.4 Measuring the loop]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) apply feedback concepts to data quality processes; (2) design measurement and correction loops; (3) avoid unstable or slow loops.
17.1 Feedback loops
A control system measures an output, compares it with a target and acts to reduce the difference. Kofi sees data quality management the same way: measure reject rates, compare with targets and correct causes. Tidewater already measures rejects but has no reliable action step, so the loop is open. He proposes a weekly review where data owners receive their reject figures and must record a corrective action for any figure above target, closing the loop. The review takes thirty minutes on Mondays.
17.2 Delay and stability
Feedback loops with long delays can oscillate. Kofi notices that Tidewater changes meter validation thresholds after each month's complaints, but complaints arrive weeks after bills, so thresholds swing back and forth. He recommends basing changes on weekly reject data, which arrives quickly, and limiting threshold changes to small steps. He explains that the same principles that stabilise pumps and valves also stabilise organisational processes that respond to data quality measurements. Threshold changes now need a written reason and a check one week after the change.
17.3 Root causes
A good loop corrects causes rather than symptoms. When readings from one district fail validation repeatedly, staff manually override them each week. Kofi traces the failures to a batch of meters with a firmware bug and asks the vendor to fix it. Manual overrides stop. He notes that correcting individual records forever is like a controller that compensates for a broken sensor without anyone repairing it, and that root cause analysis belongs in every quality loop. The vendor ships a firmware fix within a month.
17.4 Measuring the loop
Kofi measures the loop itself: time from a figure exceeding target to a recorded action, and time from action to improvement. Initially, actions take three weeks to record. After assigning named owners, they take one week. He presents loop performance to the data governance group as evidence that the process works. Prof. Varga notes that governance processes, like control systems, should be measured on how well they respond, not just on whether they exist. Improvement then follows within about two further weeks on average.
Worked example
Kofi closes an open quality loop with weekly owner actions, stabilises oscillating thresholds with faster data and small steps, fixes a firmware cause and measures loop response time.
Synthetic case. Processes are synthetic.
Errors and limits
Too many targets overwhelm owners; keep loops focused.
Exercises
- EX049 — Open loop. Why was Tidewater's quality loop open? Rubric: 3 = no reliable corrective action step;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX050 — Oscillation fix. How did Kofi stop thresholds swinging? Rubric: 3 = weekly reject data and small steps;; 2 = both;; 1 = one;; 0 = none.
- EX051 — Loop speed. How fast were actions recorded after naming owners? Rubric: 3 = one week instead of three;; 2 = partly correct;; 1 = wrong;; 0 = none.
Continue studying — lesson 17 (chapter 17 of 50)
← Chapter 16 · Course chapter index · Chapter 18 →
Continue to the next authored lesson.