How to Recover Evidence a DIY Attempt Destroyed

Why this matters

Someone got in there before you, took things apart, cleaned what was dirty, threw away what looked bad, and put it back together from memory. The stain that would have pointed at the leak is wiped. The discolored terminal is polished. The failed component is at the transfer station. You are now being asked to diagnose a system whose entire physical record has been erased by a person who was trying to help.

Most of that record is genuinely gone. But a surprising amount of it is not, and a tech who knows where the surviving copies live closes these calls in one visit instead of guessing. Evidence hides in counters, in logs, in dust, in the customer's phone, and in the shape of what was reassembled.

Before you open anything: what an abandoned attempt leaves behind

A half-finished repair is a hazard pattern, not just a mess. Lead with the isolation that matches the medium, every time.

• Electrical. Treat every conductor as landed wrong until proven otherwise. Open the disconnect, lock and tag it, and prove dead with a meter checked on a known live source immediately before and immediately after, which is the live-dead-live sequence in NFPA 70E-2021, 120.5. The duty to de-energize and lock or tag before working on a circuit that could become energized is at 29 CFR 1910.333(b)(2) under general industry rules and 29 CFR 1926.417 when the work falls under construction rules. Discharge capacitors before your hands go in.
• Stored mechanical energy. Springs left partly tensioned, an accumulator not bled, a counterweighted assembly propped on something. Isolate, block and relieve stored energy before disassembly per 29 CFR 1910.147, and confirm relief on a gauge or by physical movement rather than by the position of a handle.
• Gas. Odor at the door means everyone leaves immediately, no switch is touched, no light is turned on, no phone is used inside, and the call is made from outside. With no odor but a disturbed gas train, leak-test every joint that was opened using a listed leak-detection solution or a combustible-gas detector before any attempt to fire the appliance.
• Water plus electricity. Kill the circuit and prove it dead before anything wet is touched or moved.

Step 1: Photograph the reassembled state before you touch it

The prior attempt destroyed the original evidence. Do not let your own work destroy the second-best evidence, which is exactly how they left it. Shoot wide, then close on every fastener, every connection, every panel edge, and anything that looks recent.

Skip this and you lose your only proof of what you inherited. On any job where someone else has been inside, that photo set is what protects you if the customer later remembers the damage differently.

Step 2: Inventory what left the system

Ask, in this order, because each question is easier to answer than the last: what did you take out, do you still have it, and where is the box or bag it came in.

Then look yourself. The trash can that has not gone out, the garage shelf, the truck bed, the recycling. Packaging is nearly as good as the part, because it carries the rating, and the receipt carries a timestamp that anchors your timeline better than anyone's memory.

Skip this and you lose the failed part, which is the single richest piece of evidence in the whole job.

Step 3: Read the shadows that cleaning could not remove

Disassembly and cleaning are less thorough than they feel. Look for:

• Dust and grime shadows. A clean rectangle on a dirty surface tells you a component sat there. A shadow that does not line up with what is now mounted tells you it went back rotated, shifted, or in the wrong position.
• Witness marks. Bright metal where a fastener was recently turned, a scratch arc where something was pried, a compression ring where a gasket sat.
• Sealant and thread compound traces. Old compound on threads that now carry none, or fresh compound on a joint that was never meant to have it.
• Discoloration at the boundary. People clean the face of a part and not its back, its underside, or where it meets the panel. Heat and moisture marks survive at those edges.
• Conductor ends. Strip length, crimp marks, and re-stripped copper tell you which connections were remade and which are original.

Skip this and you lose the ability to tell what was actually disturbed, and you will accept the reassembled configuration as original.

Step 4: Recover the data copies

This is where most of the destroyed evidence actually still exists, and it is the step techs forget.

• Run-hour and cycle counters. Cumulative and rarely reset by a cleaning. They convert vague customer time into a hard axis.
• Stored fault or event history. Many controls retain a fixed number of recent events, often with a run-hour or timestamp against each. That history was written by the machine, not by anybody's memory.
• Controller and thermostat schedules and logs. They show what the system was being asked to do, and when.
• The customer's own phone. People photograph an assembly before taking it apart so they can put it back. Ask for those photos specifically. They are frequently the last image of the evidence that was destroyed.
• Utility or usage records. A step change in consumption dates the onset of a fault to a billing period even when nobody remembers.
• Your own file. Prior visit notes, readings, and the service sticker give you a known-good baseline to compare against.

Skip this and you lose the timeline entirely, which means you cannot tell whether the DIY attempt caused the current condition or merely failed to fix it.

Step 5: Anchor the timeline to events, not dates

Customers guess at dates and their guesses cluster on round numbers. They are far more reliable about events. Ask what was happening when it started: before or after the holiday, before or after the storm, before or after the other trade was here, before or after the season changed.

Then bind those events to the machine axis you recovered in step 4. "The weekend after the storm" becomes a specific run-hour reading once you know roughly how many hours a day the system accumulates.

Step 6: Stop hunting for the old evidence and recreate the fault

There is a point where further archaeology stops paying. Once you have the timeline and the disturbed-parts list, switch to producing the symptom yourself under controlled conditions and measure it live. A fault you can create on demand outranks any amount of reconstructed history, and it is the only evidence that will still be there when you want to prove the repair worked.

Skip this and you deliver a story instead of a diagnosis.

Step 7: Write the gap down, and price it

State in the record what you could not determine and why: the failed part was discarded, the surfaces were cleaned before inspection, the original configuration is unknown. Then say what that changes. Usually it means the diagnosis rests on live testing rather than on failure evidence, and it means any warranty you offer covers your work rather than a root cause you were never allowed to see.

Say it to the customer in plain terms too, without blame. Something like: "Cleaning it took away most of what I would normally read, so I am going to make it fail on purpose instead. That takes a little longer."

Worked example: the counter told the story the cleaning erased

The complaint is a fault that shuts the system down and clears itself. The customer had already pulled the assembly, cleaned it thoroughly, and put it back a few weeks earlier. Nothing visible survived.

The physical read still produced one thing. A dust shadow on the mounting panel did not match the current position of the component sitting on it, which meant it went back rotated from where it had lived for years.

The data recovery produced the rest. The run-hour counter read 4,180 hours. The control retained its last 10 fault events, each stamped with a run-hour value, and they spanned 3,905 to 4,175 hours.

The customer could not give a date for the cleaning, but they could anchor it: the weekend after the windstorm. Mapping that to the system's own accumulation put the cleaning at about 4,150 hours.

Now split the stored events on that line. 7 of the 10 events fall at or below 4,150, and 3 fall above it.

Two conclusions come straight out of that split, and they point in different directions:

• Before the cleaning: 7 events across the span from 3,905 to 4,150, which is 245 run-hours, so one event per 35 run-hours.
• After the cleaning: 3 events across the span from 4,150 to 4,180, which is 30 run-hours, so one event per 10 run-hours.

The fault clearly predates the cleaning, so the customer did not cause it and telling them so is both true and worth saying. But the rate after the cleaning is 35 divided by 10, which is 3.5 times the rate before it, so the cleaning made an existing problem substantially worse. Both facts came out of a counter and a stored event list, on a system where every trace of physical evidence had been scrubbed off.

The rotated component explained the second finding, and correcting its orientation dropped the rate back toward the original interval. The original fault was separate and was found by recreating the condition on purpose in step 6.

Why the run-hour axis and not the calendar. A calendar count would have shown the events bunching in recent weeks and invited the obvious wrong conclusion, that the fault is new and accelerating on its own. Run-hours normalize for the fact that the system ran far more in the weeks after the storm. Any time you have a machine-side counter, use it as the axis and treat calendar dates as a translation layer.

What this read cannot claim. The control holds 10 events and it was holding 10, which means the list is full and rolling and older events have already been overwritten. So 3,905 hours is where the record begins, not where the fault began, and the honest statement is that the fault had already been firing for at least the 245 run-hours between 3,905 and the cleaning. Had the list come back with only 4 entries in a control that stores 10, the earliest stamp would genuinely mark the onset, and you could say so.

How to verify you got this right

• Every number in your conclusion traces to a machine-side source or a photograph, not to a customer's recollection. Recollection is fine for anchoring an event and unreliable for anything you will act on.
• Your timeline is stated in run-hours or cycles where a counter exists, with the calendar translation shown separately so the next tech can check your conversion.
• You can produce the fault on demand. If you cannot, say so explicitly rather than letting a reconstructed history stand in for a live test.
• The record names what is unknowable. A file that reads as if you had full evidence when you did not will be trusted more than it deserves, by you most of all, on the second visit.

References

• 29 CFR 1910.333(b)(2), and 29 CFR 1926.417 for the same work under construction rules, on de-energizing and locking or tagging circuits before work
• NFPA 70E-2021, 120.5 for the live-dead-live instrument proving sequence
• 29 CFR 1910.147 on isolating and relieving stored mechanical energy before disassembly
• Manufacturer documentation for stored fault history depth, counter behavior, and what a reset clears
• See related: How to Log an Intermittent Fault Over Days