Is a recurring problem the same one coming back, or a new one?

This comparison applies to process, product and equipment problems in specialty chemical use where an earlier case is on record or can be rebuilt. It does not cover injuries or safety incidents, which follow your site's incident investigation procedure, and it does not replace a regulated corrective action procedure where your sector requires one.

What does a recurring problem look like next to an earlier case?

A recurring problem looks like an earlier case on the surface: the same symptom, often on the same line or at the same customer, after a fix that seemed to work. The foam is back, the rust spots return, the filter blinds early again. What the surface hides is whether anything underneath matches. Two cases can share a symptom and differ in product lot, water source, temperature, load or the part that was replaced.

The first useful step is to put the two cases side by side as records, not as memories. Pull the earlier case file: what was observed, on which equipment, with which product and lot, under which readings, what was done and what result was accepted as success. Then write the current case in the same fields. Gaps matter as much as matches. A field that was never recorded in the earlier case cannot be used to call the problem the same one, and it should be marked as unknown rather than assumed equal.

Software teams face the same question with returning bugs, and Bugnet's guidance treats the same crash signature returning as the same underlying issue (Bugnet, 2026). In a chemical process, a signature is rarely that clean, so the comparison has to run across conditions, not one identifier.

What makes a recurring problem the same problem rather than a new one?

A recurring problem is the same problem when the cause the earlier fix targeted is still acting, either because it was never removed or because the fix stopped holding. It is a new problem when a different cause produces a similar symptom. ICH Q10, the pharmaceutical quality system guideline, defines corrective action as action to eliminate the cause of a detected non-conformity, taken to prevent recurrence (ICH Q10, 2008). Recurrence is therefore evidence about the cause, not only about the symptom.

Unremoved cause

The earlier fix treated the symptom and the cause stayed. Reliable names treating symptoms rather than causes as the most frequent driver of recurring work orders (Reliable, accessed 2026). The sign is a fast return under unchanged conditions. OSHA's metalworking fluids manual gives a fluid example: refilling without cleaning the delivery system exposes new fluid to "the same conditions that forced you to change the fluid in the first place" (OSHA Metalworking Fluids Best Practices Manual, accessed 2026).

Lapsed fix

The fix removed the cause for a while, then stopped working: an additive depleted, a filter loaded, a setting drifted back, a procedure stopped being followed. The sign is a return at a similar interval after each fix.

New cause with similar symptoms

A different cause arrived: a new lot, a changed water supply, a replaced part, a new operating mode.

How can you tell a recurring problem from a new one on site?

You can tell a recurring problem from a new one on site by checking five things against the earlier record and reading where they point together, because no single check settles it. The table below decides whether the current case is an unremoved cause, a lapsed fix or a new cause:

The row that changes the decision most often is the last one. If the earlier fix had no success criterion, or nobody checked it, the earlier case cannot show that the cause was removed, so the current case should be handled as a possible unremoved cause. When the conditions rows show a change and the symptom rows differ, a new cause is more likely, and the earlier fix should not simply be repeated. Fill every row before deciding, and write "unknown" where the earlier record is silent. Two or three unknown rows are a finding in their own right: they say the earlier case cannot settle the question, and the current case has to be measured in full.

How do you check whether the last fix ended the problem or only delayed it?

You check whether the last fix ended the problem or only delayed it by testing the fix against the success criterion it was given before it was applied, and by checking whether the cause it targeted is gone, not only whether the symptom paused. A symptom that stops for a few weeks proves little if the problem used to return at about that interval anyway.

Start with the earlier record. Look for four things: the measure that defined success, its threshold, the window over which it had to hold, and who judged it. If those were fixed before the fix, the result can be read fairly. If they were written after the result was known, the record shows what happened, not whether the fix worked. ICH Q10 states that for commercial manufacturing the effectiveness of corrective and preventive actions should be evaluated (ICH Q10, 2008).

The case-based reasoning literature makes the same point about time. The results of applying a solution may take some time to appear, and a case learned in the meantime has to be marked as a non-evaluated case (Aamodt and Plaza, 1994). Treat an earlier fix the same way. If its window never closed with a check, its status is not evaluated, and calling the current problem new on the strength of it is a guess.

How do you stop a recurring problem from coming back again?

You stop a recurring problem from coming back again by tying the next fix to the cause it is meant to block, fixing its success and stop criteria before it starts, and recording the case so the next comparison can be made from records. Each part closes one way the earlier attempt failed.

First, name the cause link the fix is meant to break, such as tramp oil entering from a leaking way-lube seal, rather than the symptom it should remove. A fix that names only the symptom cannot be tested against the cause. Second, write the success criterion, the stop criterion, the judge and the end date of the window before the fix is applied. Third, record the conditions the fix was proven under: product and lot, water, temperature, concentration and equipment.

OSHA's metalworking fluids manual recommends tabulating physical observations, laboratory analyses and additions so that relationships and trends in the data can be spotted (OSHA Metalworking Fluids Best Practices Manual, accessed 2026). The same habit works for any recurring problem. Reliable suggests flagging any asset with three or more corrective work orders for the same failure mode within a rolling 12-month window, and making that flag trigger a root cause review before the next repair closes (Reliable, accessed 2026). Record failed attempts as well, with their conditions, so the next person knows which combination did not hold.

When should a recurring problem reopen the earlier corrective action?

A recurring problem should reopen the earlier corrective action when the comparison points to an unremoved cause or a lapsed fix, or when the earlier success criterion was never met or never checked. A new cause gets its own case, with a link to the earlier one so the history stays visible. Reliable suggests that a second occurrence should trigger a 5 whys analysis at minimum and a third a formal investigation with engineering involvement (Reliable, accessed 2026). IEC 62740:2015 describes the basic principles of root cause analysis and specifies the steps such a process should include (IEC 62740:2015).

Bring in a specialist, such as the product supplier's technical service or a process engineer, when the comparison shows no changed condition and the problem still returns, or when lots need retained-sample testing. Handle samples, cleaners and biocides under each product's safety data sheet (SDS) and your site's chemical safety rules. If your site is certified to ISO 9001, check the corrective action requirements of the edition you are audited against, since ISO published ISO 9001:2026 on 16 September 2026 (ISO, 2026). Lubinpla works this comparison from your own documents and site history: it compares the current case with past cases to judge the recurrence signals and whether the earlier response actually worked, and returns one cited document for your review.