Chapter 20 — Troubleshoot incomplete or contradictory case records
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes and connection"]
N1["20.1 Types of defect"]
N2["20.2 Finding defects"]
N3["20.3 Diagnosing causes"]
N4["20.4 Correcting records"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["20.1 Types of defect"]
N2["20.2 Finding defects"]
N3["20.3 Diagnosing causes"]
N4["20.4 Correcting records"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX058"]
[Learning outcomes and connection]
|
v
[20.1 Types of defect]
|
v
[20.2 Finding defects]
|
v
[20.3 Diagnosing causes]
|
v
[20.4 Correcting records]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes and connection
You will be able to (1) detect incomplete or contradictory case records systematically; (2) diagnose their causes in process, tooling or data; and (3) correct records without destroying the original history. Chapters 17–19 built tools and feedback; real records still go wrong, and a technologist must repair both the record and the cause.
20.1 Types of defect
- Missing: no triage time, no closure reason, no owner for a period.
- Contradictory: action time before decision time; status "closed" with open tasks; severity S4 but a regulator notification recorded.
- Inconsistent with evidence: case says host isolated at 10:00; endpoint logs show it communicating at 10:30.
- Duplicated: two cases for the same incident with diverging facts.
The reception PC case was a defect of the third kind: the record said isolated at 10:02 while endpoint telemetry showed DNS queries at 10:27. Fernmoor's nightly checks are written to find each of the four kinds.
20.2 Finding defects
Run automated checks against the case database: required fields by status, ordering constraints (opened ≤ triage ≤ decision ≤ action ≤ closed), cross-field rules (S1 requires an incident lead), and reconciliation with evidence sources (claimed containment vs telemetry). Run them nightly and in the monthly report. Sample a few cases manually each month as well; automated checks only find the defects you anticipated. The nightly check found the reception PC defect by comparing the recorded isolation with endpoint telemetry, a defect no required-field rule could have caught.
20.3 Diagnosing causes
Ask why each defect happened. Typical causes: a field that cannot be filled on mobile; clocks on a tool set to local time; an automation writing the action time when the job was queued, not when it ran; analysts working in chat and updating the case later from memory; unclear definitions. Fix the cause, not only the record — otherwise the defect returns. The reception PC defect had the third cause: the automation wrote the time the isolation request was queued, while the agent applied it only when the laptop reconnected. The fix recorded both times and alerted if confirmation was late, so the defect cannot recur silently. Without that change, every offline device would produce the same false record.
20.4 Correcting records
Never overwrite silently. Add a correction entry: field, old value, new value, source of the correct value, who corrected, when. The history must show both. For cases with legal or regulatory relevance, involve counsel before correcting anything material. In the reception PC case, the correction entry recorded the queued time of 10:02, the applied time of 10:41 and the agent log as the source. The original value stays in history, so a reviewer can see what was believed at the time and why it changed. The 25 minutes of activity were added to the case scope at the same time.
20.5 Worked example (synthetic): isolation that wasn't
Fictional. The nightly check flagged FCS-245: "host reception-pc-3 isolated 10:02 (action recorded)" but endpoint telemetry showed DNS queries to an unknown domain at 10:27. Diagnosis: the automation recorded the time the isolation request was queued; the agent on that PC was offline (laptop lid closed), so isolation applied only at 10:41 when it reconnected. The 25 minutes of activity were real and in scope. Corrections: action time updated with a correction entry (10:02 queued, 10:41 applied, source agent log); case scope extended to the 10:27 domain. Cause fix: the automation now records requested_at and confirmed_at separately and alerts if confirmation does not arrive within 5 minutes; the runbook adds "verify isolation in console".
20.6 Common errors and limits
- Fixing records by hand without fixing the process that broke them.
- Rewriting history to look tidy.
- Trusting automation timestamps without knowing what event they record.
- Checks so noisy that analysts ignore them.
The reception PC case shows the remedy for each. The record was corrected with a visible entry rather than rewritten, the automation was fixed so the defect would not return, and the team learned exactly which event the timestamp recorded. The nightly checks were kept specific enough that analysts treat a flag as worth investigating, rather than background noise.
Exercises — chapter 20
Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.
EX058 — Check rules. Steps: write six automated consistency rules for the case database. Rubric: 3 = six precise rules covering required fields, ordering, cross-field, evidence reconciliation; 2 = four; 1 = vague; 0 = none.
EX059 — Correction entry. Steps: write the correction entry for FCS-245. Rubric: 3 = field, old, new, source, who, when, reason; 2 = missing source; 1 = overwrite; 0 = none.
EX060 — Root cause. Steps: for "triage times missing for 30% of out-of-hours cases", list three plausible causes and a test for each. Rubric: 3 = three causes with discriminating tests; 2 = causes without tests; 1 = one; 0 = none.
Chapter synthesis
Check records automatically and by sampling, diagnose each defect to its process or tooling cause, correct with visible history, and fix the cause so the defect does not return.
Continue studying — chapter 20 of 30
← Chapter 19 · Course chapter index · Chapter 21 →
Continue to the next authored lesson.