Key takeaway

A code-clear event changes the diagnostic record. It does not prove that the vehicle completed the relevant self-tests or that the defect stayed resolved.

Keep the diagnostic states apart

A fleet archive changes a job to repaired when the technician clears the scanner’s fault-code display. That event may be real, but the outcome label is stronger than the observation. A useful history retains the repair action, diagnostic-clear action, lamp state, code classes and monitor status as separate events.

California BAR describes readiness monitors as OBD self-tests and explains that operating conditions affect completion. It also distinguishes supported data and reported MIL, trouble-code and monitor observations. EPA’s June 2001 technical report supplies the historical explanation that clearing fault-code memory resets readiness. That report is not used here as today’s inspection rule.

Replay a fictional three-visit history

Consider a hypothetical OBD-equipped vehicle V8 for which the listed monitor and permanent-code function are explicitly assumed supported. At the first visit, its MIL is commanded on, fault X is stored and the relevant monitor is complete. A repair and scanner-clear action are recorded. Immediately afterwards, the ordinary code is absent and MIL is off, but the monitor is incomplete and a permanent code remains.

At a later observation, the monitor is complete, the recorded ordinary code is absent, MIL is off and the permanent code is no longer reported. The example stipulates that this later state was read from the vehicle, not erased by the technician. It documents that bounded later observation; it does not establish that every emission system passed or that the problem can never return.

StageRetained fictional diagnostic observationOutcome interpretation
Before repairMIL on; fault X stored; relevant monitor completeFault observation linked to visit
Immediately after clearMIL off; ordinary code absent; monitor incomplete; permanent code remainsReset recorded; self-test outcome not yet established
Later readbackRelevant monitor complete; stated codes absent; MIL offBounded post-repair observation retained
No later readbackOnly clear event retainedFollow-up unknown, not confirmed success

A permanent code is its own field

BAR explains that permanent DTCs cannot be erased by a scan-tool clear or battery disconnection; the OBD system clears them after it verifies the relevant condition. Preserve the code category and the actual response rather than exporting one undifferentiated fault_codes string. Absence of an ordinary stored code should not silently stand for absence of a permanent code.

Equally, not supported, incomplete and not observed are different states. A failed communication attempt is not a monitor pass and is not evidence that the vehicle lacks the function. Retain scanner/software identity, response time and available raw response references in the controlled technical record. Avoid inventing supported status from a blank spreadsheet cell.

Separate technical history from inspection disposition

BAR’s reference contains California-specific fuel, model-year and vehicle exceptions. A real inspection decision requires the applicable jurisdiction, date, vehicle and current procedure. This article intentionally does not translate its fictional timeline into a Smog Check pass or a nationwide readiness threshold.

A fleet evaluator may instead ask whether a repair history preserves enough evidence to study recurrence. In that case, link the later scan to the same vehicle/component and retain the elapsed observation period. A complete monitor at one readback does not supply months of follow-up. Keep customer-reported symptoms and mechanical test results alongside diagnostic states without merging them into one binary ground-truth label.

Use a precise metadata question

The completed internal request for V8 is whether the archive retains clear events and subsequent supported-monitor readbacks. If later observations are absent, describe that gap. Do not ask staff to erase the history or drive a generic cycle merely to populate a dataset.

Inventory can record diagnostic layers; Due diligence can establish the intended outcome window. Vehicle identifiers, driver journeys and customer repair records need separate disclosure review. A fictional state timeline explains the structure without transmitting those records or presenting VOID as a diagnostic or inspection authority.

Tools for this decision

Data inventory builder →Diligence question builder →