1308 S College St, Seattle, WA 98144, US
Editorial Desk: Mon - Fri 08:00 - 18:00 EST
Log Context Sheet

The DTC Existed Before the Test

A code found after the test is not automatically a code caused by the test.

2026-06-17 Lisa Moreno 6 min read
CASE PROTOCOL CONTEXT REVIEW
REVIEW FOCUS: Pre-Existing Fault Code Context
DTC STATUS: Active before first recorded session
SHEET OUTCOME: Test Results Reclassified — Contaminated State
The DTC Existed Before the Test
Executive Summary & Scope

The Code That Was Already There

A stored diagnostic trouble code sat in memory before the test drive ever happened. Because nobody checked first, half a day of session data was later reinterpreted: the vehicle had never entered the test in a clean state at all.

Key Facts & Session Baseline
  1. Pre-Existing DTC: Active in memory before session 1
  2. Discovered: After two review passes, during handoff
  3. Impact: All “post-change” observations contaminated
  4. Outcome: Sessions reclassified; retest after DTC resolution
Reviewed against the Log Context Sheet standard
Examine Full Sheet
Log Context Sheet

1. The Question

Did the logged session trigger the misfire counter DTC, or was it already stored?

After a diagnostic logging session, a scan showed a pending misfire-history code. The immediate assumption was that the test drive caused it. A freeze-frame review told a different story: the code's stored timestamp and operating-hours counter predated the session by weeks.

Fault codes carry no loyalty to when they were found. A code read after a session describes the state of memory, not the cause of it — yet post-test scans get treated as post-test evidence almost by reflex.

The real question was chronological: when did the misfire counter first increment? Freeze-frame data and the operating-hours counter answer that directly — but only if someone thinks to read them before assuming.

2. The Vehicle State

2018 compact crossover, 87,000 km. A full DTC scan including pending and history codes was not performed before the recording session began.

The pre-test state of the fault memory was, effectively, unknown until it mattered.

At 87,000 km, a history of stored and cleared codes is the rule, not the exception. Without a pre-session scan, every old entry in fault memory becomes a suspect for whatever the new session was testing.

A one-minute scan before recording — pending, stored, permanent, and history entries with their timestamps — turns the fault memory from a trap into a reference. It is step zero precisely because it cannot be done retroactively.

3. The Conditions

The session itself was a moderate-load road drive — nothing in the recorded channels approached conditions typically associated with misfire counting.

The drive looked innocent. The timing looked guilty. Only the stored history was objective.

The drive itself never approached the load region where misfire counting typically runs: moderate throttle, suburban speeds, no sustained high-load pull. Suspicion rested on sequence — 'we tested, then we found a code' — and sequence is the weakest form of evidence.

Documenting what the session did not do mattered here. The logged channels showed an ordinary drive, which is exactly the alibi the session needed once the timeline was checked.

4. The Recorded Window

The recorded window covered the drive cleanly. The diagnostic event in question was outside it by an order of magnitude in time.

The log could not acquit itself until the freeze-frame data was read.

The recording window was honest but narrow in time: it covered the drive, while the diagnostic event being blamed on it sat weeks in the past. No amount of zooming inside the file could touch an event outside it.

This is the mirror image of the missed-event case: here the 'event' was never going to be in the window at all. The window had to be extended backwards in a different way — through stored vehicle memory, not more recording.

5. The Observation

Freeze-frame operating-hours and the history counter placed the code's first registration well before the test date. The session did not produce the code — it merely revealed that nobody had looked.

Checking DTC context before logging would have documented this in one line.

Freeze-frame hours placed first registration roughly three weeks before the test date, under a highway load profile nothing like the logged commute. The session was cleared by the vehicle's own bookkeeping — evidence that existed the whole time, unread.

The lesson generalises: a finding's timestamp is part of the finding. Reading 'a code exists' as 'the test caused a code' skips the one field that separates correlation from sequence.

6. The Follow-Up Question

Make 'scan and record existing DTC context' step zero of every session — including pending, permanent, and history codes with their stored timestamps.

Every later finding then stands on a documented starting point.

The updated session checklist now opens with fault-memory capture: screenshot or record all DTC categories before the wheels move, then again after. New entries between the two scans are the session's to explain; older ones are background.

One line of pre-test documentation would have ended this case in a minute. The vehicle already knew the answer — the procedure just had to ask it in the right order.

What was happening when this data was recorded? If the sheet cannot answer that, the log is not evidence yet — it is just a file.
— Lisa Moreno, LogContext Journal
Field Notes

Key Takeaways Box

01

Check the Code First

A DTC that predates the session changes what every channel in that session means. Pre-check is step zero of any logging plan.

02

Clean State Is a Prerequisite

A vehicle running under an active fault is not a control group — its data answers a different question than the one you asked.

03

Document the Pre-Check

“No codes present at session start” is itself evidence. It belongs on the sheet, not in memory.

Parameters

Session Specifications

DTC Present at Start Yes — undetected
Sessions Affected 2 drives
Discovery Point Handoff review
Follow-Up Action Resolve DTC, repeat baseline
Peer Discussion

Comments & Verification Notes

No peer comments recorded yet. Be the first to submit a technical note.

Leave a Peer Review Comment

Thank you! Your comment has been submitted and is awaiting moderation.
Standard

Review Guidelines

Comments are reviewed against the Log Context Sheet standard. Please keep observations tied to the recorded window, vehicle state, and conditions — not to tuning advice.

Peer-Verified Workflow
Reference

A Log Context Sheet is the journal's standard review format: Question, Vehicle State, Conditions, Recorded Window, Observation, and Follow-Up Question. It keeps every conclusion tied to what was actually happening while the data was recorded.

Newsletter & Dispatch

Stay Informed on Verified Diagnostic Methodology

Receive quarterly white papers, protocol updates, and raw log interpretation frameworks directly from our engineering desk.