◇ OpenCyber Academy
Technologist · Chapter 9 · English

Chapter 9 — Fixing problems at the source

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 9 — Fixing problems at the source

Lesson map

Lesson 09 published. Map, example, EX025.

flowchart TD
  N0["Learning outcomes"]
  N1["9.1 Cleaning versus fixing"]
  N2["9.2 Source controls"]
  N3["9.3 Measuring effect"]
  N4["9.4 Remaining cleaning"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX025"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["9.1 Cleaning versus fixing"]
  N2["9.2 Source controls"]
  N3["9.3 Measuring effect"]
  N4["9.4 Remaining cleaning"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX025"]
[Learning outcomes]
    |
    v
[9.1 Cleaning versus fixing]
    |
    v
[9.2 Source controls]
    |
    v
[9.3 Measuring effect]
    |
    v
[9.4 Remaining cleaning]
    |
    v
[Worked example] --> [Exercise EX025]

Learning outcomes

You will (1) distinguish source fixes from downstream cleaning; (2) implement source controls; (3) measure the effect.

9.1 Cleaning versus fixing

Ravi could correct invalid priorities each night with a script, converting lowercase letters and guessing blanks. Ms. Moreau asks what would happen next month: the same errors would arrive again, and guesses might be wrong. She explains that cleaning downstream treats symptoms, while fixing at the source prevents errors. Cleaning may be needed temporarily, but it should be paired with a source fix and recorded so that reports can show what was changed. Ravi agrees to pursue source fixes first, with temporary cleaning recorded.

9.2 Source controls

Ravi works with the contractor portal team to convert priority codes to uppercase and reject blanks before submission. In the housing system, call handlers now select priority from a drop-down rather than typing. For emergencies, a new field records the time the tenant first reported the problem, so jobs created later keep a correct raised time. Each change is tested with synthetic jobs before release to confirm it behaves as intended. The portal team and IT release the changes together after the tests pass, with the steward's approval.

9.3 Measuring effect

After the changes, Ravi reruns the validation on a new month of synthetic jobs designed to match the new process. Invalid priorities fall sharply, and completion-before-raised errors fall as call handlers use the new field. He reports the before-and-after comparison to the steward, noting that the new month's synthetic data reflect his assumptions about the changes and that real monitoring will confirm whether the improvement holds. He schedules a check on real monitoring results three months after the changes, with the steward responsible for reviewing them and reporting to the repairs manager.

9.4 Remaining cleaning

Some old records still contain errors. Ravi and the steward decide to correct historical priorities where the correct value can be confirmed from job descriptions, marking each correction with a reason code, and to leave others flagged as unknown. He notes that corrections must be traceable, so that anyone reviewing past reports can see which values were changed, when and why, and that guessing silently would damage trust in reports. The flagged records are listed in a separate report, so managers know which past figures carry uncertainty.

Worked example

Ravi chooses source fixes over nightly cleaning, adds uppercase conversion, blank rejection, drop-downs and a first-report time field, measures the effect and corrects old records only with traceable reason codes.

Synthetic case. Changes are synthetic.

Errors and limits

Silent downstream corrections hide recurring source errors.

Exercises

Continue studying — lesson 09 (chapter 09 of 30)

← Chapter 08 · Course chapter index · Chapter 10 →

Continue to the next authored lesson.