Automatic Diagnostic Capture¶
Workflow — instantiates Intermittent Failure Capture
Automatically saves diagnostic details when a trigger condition is met, reducing dependence on the investigator being present.
Automatic Diagnostic Capture is a workflow in which meeting a defined trigger condition automatically saves a bundle of diagnostic detail and routes it onward to whoever will act on it — with no human required to be present at the moment of failure. Its defining move is that it closes the loop from trigger to saved-and-delivered evidence automatically, removing the dependence on the investigator happening to be watching. Its distinct contribution among its siblings is the hand-off: it presumes a trigger already exists, and its job is to snapshot the state and deliver it into a follow-up path so the evidence is waiting when someone finally engages. It is neither the detector that discovers rare events nor the human review that interprets them.
Example¶
A car intermittently stumbles under load, but never while it is up on the mechanic's lift. The engine control unit runs an automatic diagnostic capture: when any sensor reading crosses a fault threshold and sets a diagnostic trouble code, the ECU immediately records a "freeze frame" — engine RPM, load, coolant temperature, fuel trim, and throttle position at that instant — and stores it against the trouble code. When the car is next plugged into a scan tool, the technician retrieves both the code and the exact conditions at the moment of the fault, delivered straight into the diagnostic workflow. The driver was alone on the highway when the stumble happened; neither the capture nor the hand-off to the technician needed anyone to be present.
How it works¶
- A defined trigger — a fault code, a threshold breach — fires automatically without human action.
- On fire, the workflow snapshots the relevant diagnostic state at that instant.
- It attaches the snapshot to an identifier and routes it into the follow-up path — queued for the next technician, on-call, or investigator.
- The investigator engages later, finding the evidence already captured and delivered rather than lost with the episode.
Tuning parameters¶
- Trigger set — which conditions auto-capture. Broader catches more episodes but floods the follow-up queue with low-value captures.
- Snapshot contents — which parameters are frozen. Richer diagnoses more but costs storage and review time.
- Routing target and urgency — where captures go and how fast they demand attention.
- Overwrite policy — when many captures fire, whether to keep the first, the last, or the worst.
When it helps, and when it misleads¶
Its strength is that it decouples capture from human presence and guarantees the evidence reaches an owner, so an unrepeatable episode is not lost merely because no one was watching. Its named hazard is automation complacency[n1] — once capture is automatic, people stop actively investigating and assume the system "has it," so gaps in what is captured go unnoticed. Its central failure mode is a snapshot that freezes the wrong instant — the code sets after the causal moment — or a routed capture that piles up in a queue no one drains, which is capture without diagnosis. The classic misuse is treating the mere presence of automatic capture as proof the problem is being handled. The guarding discipline is to verify that the captured frame actually spans the fault, and to make the follow-up path owned, not merely automatic.
How it implements the components¶
Automatic Diagnostic Capture realizes the trigger-to-hand-off side of the archetype — saving state on a trigger and delivering it, not detecting rare events or interpreting them:
trigger_condition— the defined fault code or threshold breach that auto-initiates capture without a human.state_snapshot— the freeze-frame of diagnostic state saved the instant the trigger fires.follow_up_diagnostic_path— routes the saved capture to whoever will act on it, so the evidence is not stranded in the system that produced it.
It does not retain the pre-trigger lead-up in a rolling window (capture_window) — that backward view is flight_recorder's; and it does not interpret or compare the captures once delivered (recurrence_analysis) — that judgment is post_episode_evidence_review's.
Related¶
- Instantiates: Intermittent Failure Capture — automates the capture-and-delivery step so no one must be present at failure.
- Consumes: Rare Event Monitor — a detector can supply the trigger this workflow acts on.
- Sibling mechanisms: Flight Recorder · Trigger-Based Debug Trace · Incident Snapshot · Symptom Diary · Rare Event Monitor · Post-Episode Evidence Review · Black Box Log
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Automatically saves diagnostic details when a trigger condition is met, reducing dependence on the investigator being present, making its operative form a state-dependent executable control that senses, filters, routes, or actuates during operation.
Independent corroboration: The frozen evidence defines Automatic Diagnostic Capture as 'Automatically saves diagnostic details when a trigger condition is met, reducing dependence on the investigator being present', so its operative form is Control, Automation & Runtime.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Engineering instrumentation developed triggered recording of system state when intermittent faults occur.
Related originating lineages:
- Aviation & Aeronautics — Flight-data and event recorders provide a canonical safety-critical lineage.
- Computer Science & Software Engineering — Crash dumps, traces, and observability pipelines automate snapshot and routing.
Review resolution: Engineering design is the agreed primary lineage. Flight-data recording and software crash diagnostics independently established trigger-based evidence capture, supporting convergence and multi-domain reach without Encyclopedia synthesis.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Automation complacency is the well-documented tendency of people to reduce their own vigilance when an automated system is handling a task, so that failures of the automation — here, gaps in what gets captured or a follow-up queue no one drains — go undetected. Automating capture does not automate diagnosis. ↩