> ## Documentation Index
> Fetch the complete documentation index at: https://docs.assetinfinity.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Root cause and corrective actions

> Investigating why something keeps happening, and tracking whether what you did about it worked.

Where a repeating problem is investigated, and where the actions that came out of it are followed
until somebody can say whether they worked.

The screen opens on the register rather than on the investigations, because an investigation that
reached a root cause changes nothing on its own. What changes something is an action, done, checked,
and found afterwards to have worked.

## What the header counts

| Figure              | Meaning                                                       |
| ------------------- | ------------------------------------------------------------- |
| **Investigations**  | How many are on record                                        |
| **Actions overdue** | Actions past their due date and not done                      |
| **Did not work**    | Actions somebody reviewed and found had not fixed the problem |

The third is the one the screen exists for. An action that was completed, confirmed and then
reviewed as ineffective is the register saying the investigation was wrong — and no open/closed
column can express it.

Two chips sit above the tabs whenever they apply: actions reviewed and found not to have worked, and
actions completed that nobody has confirmed. Both jump to the **Actions** tab.

## Opening an investigation

An investigation is opened against an asset — usually because the same thing has gone wrong more
than once. [Reliability](/assets/reliability) raises an *Investigate* recommendation when it spots
one.

<Steps>
  <Step title="Name the asset">
    The machine the investigation is about.
  </Step>

  <Step title="State what is being investigated">
    One sentence, agreed before anybody starts. This is the problem statement and it stays at the top
    of the investigation.
  </Step>

  <Step title="Choose a method">
    **Five Whys** — a chain. **Fishbone** — causes grouped by category. **Fault tree** — branches
    carrying gates. Or **something else**, if none of them fits how your team works.
  </Step>

  <Step title="Set a due date">
    Optional, and worth setting. An investigation with no date is one nobody is waiting for.
  </Step>
</Steps>

## Findings

The investigation screen draws the findings the way the method reads. A Five Whys is a chain of
indented steps, with an **And why is that?** button under each one. A fishbone is one level grouped
by category. A fault tree is branches.

Each finding carries:

* **The statement** — what you believe.
* **The evidence** — what makes it more than a guess.
* **Root cause**, if you mark it as one. More than one finding can be marked.

A finding whose evidence has been confirmed shows as **evidenced**. Change its evidence afterwards
and it stops being evidenced, because the person who confirmed it confirmed something else.

## Concluding

Write what the investigation concluded and press **Conclude**.

<Warning>
  Concluding is refused unless at least one finding is marked as the root cause. The refusal comes
  from the server, not from the button — a conclusion with nothing behind it is an opinion.
</Warning>

A concluded investigation that still has actions open is flagged on the list. That is a diagnosis
nobody treated.

## Actions

An action belongs to an investigation, and may be attached to one finding or to the investigation as
a whole. It is either **corrective** — fix this one — or **preventive** — stop it recurring.

Each action carries a description, an owner and a due date. Its **effectiveness review** is set
ninety days after the due date unless you say otherwise, because a review dated the day the work
finished asks whether a change worked before anything has had time to recur.

### Standing

The register is sorted by what an action is waiting for rather than by date, so the rows that need a
decision come first.

| Standing                          | What it means                          |
| --------------------------------- | -------------------------------------- |
| **Outstanding**                   | Not done yet, still within its date    |
| **Overdue**                       | Not done, past its date                |
| **Awaiting verification**         | Completed, and nobody has confirmed it |
| **Verified**                      | Somebody confirmed it was done         |
| **Awaiting effectiveness review** | Confirmed, and the review is now due   |
| **Effective**                     | Reviewed, and the problem stopped      |
| **Did not work**                  | Reviewed, and it did not               |
| **Closed**                        | Finished with                          |

### Verifying, and reviewing

**Verify** records that you have seen the action done. It is deliberately a separate act from
completing it.

**Did it work?** asks the other question, weeks later: not whether the action was carried out, which
is already recorded, but whether the problem stopped. Both answers are recorded the same way, with
room for a note on what has happened since. *It did not* is a result, not a failure to record one.

## Failures

The third tab lists work orders that have been classified — what kind of failure it was, what caused
it, and by what mechanism. A work order only becomes a failure when somebody says what kind of
failure it was; until then the product can count downtime but can say nothing about modes.

Each row carries the failure mode, the cause, the mechanism and the severity, and is marked
**happened before** where the same thing has occurred on that component already. That mark is worked
out across the whole history rather than across the page you are looking at.

<Note>
  Failure modes, causes and mechanisms are three separate lists, and your organisation owns all
  three. A new organisation starts with a working draft of each so the first failure classified goes
  somewhere sensible; every entry can be renamed, added to or retired. They are edited in
  Administration — see [administered lists](/config/administered-lists).
</Note>

Keeping the three axes apart is the point. *Bearing seized* is a mode, *misalignment* is a cause and
*fatigue* is a mechanism. Collapse them into one list and you get a chart of "bearing failure" that
tells nobody whether to buy a better coupling or train a fitter.

## Who can do what

Reading the register follows your reliability permissions. Opening an investigation, adding findings
and actions, verifying and reviewing all need permission to edit investigations — Maintenance
Manager and the two administrator roles, by default. Classifying a failure is a separate and much
wider permission, held by supervisors and technicians too. See [roles](/setup/roles).


## Related topics

- [What this system does](/introduction.md)
- [Core concepts](/core-concepts.md)
- [Reliability](/assets/reliability.md)
- [Finding your way around](/get-started/navigating.md)
- [Inside a work order](/work/work-order-detail.md)