Corrective actions that quietly never close

The situation

A nonconformance is raised against a batch or a process. It needs containment, an investigation, a corrective and preventive action, and — the part that is always skipped — a check months later that the action actually worked. Rework loops back on itself, sign-off has to be attributable, and an inspector will ask to see the whole chain.

These are illustrative scenarios showing how the products are used, not customer case studies.

What gets modeled

The structure as it would actually be defined — sections that repeat are marked.

How it gets built

In the order somebody would actually do it. Each step names the capability it rests on, so it can be checked against the product pages.

1. 1

   Model actions under the cause they address

   Root causes repeat, and the actions that address each one nest inside it. That shape is what makes "which action was this, and why" answerable — a flat action list with a nonconformance reference loses the link the moment there is more than one cause.

   What it uses: Sections that nest and repeat to any depth

2. 2

   Turn on history before the first deviation

   History is enabled on the schema, so every write keeps a snapshot and any retained point can be restored, with the restore itself recorded. What the investigation said before it was revised is part of the record rather than lost to the revision.

   What it uses: Snapshot per write, restore to any retained point

3. 3

   Contain first, investigate second

   A trigger starts the run when the nonconformance is created, with filters routing by severity. Conditional links separate the containment path from the full investigation, with an explicit default so an unclassified deviation does not fall through a gap.

   What it uses: Record triggers with filters, conditional links with an explicit default

4. 4

   Loop back for rework, but not forever

   An investigation sent back for more evidence loops to an earlier step. The loop carries a re-entry cap that fails loudly rather than spinning, so a case that keeps bouncing surfaces as a failure somebody sees instead of a run that never ends.

   What it uses: Rework loops with a re-entry cap that fails loudly

5. 5

   Sign the approval the way an inspector expects

   Approving the investigation and the action plan requires re-authentication at the moment of signing, with a reason from your own codes. The decision is sealed once recorded. That is the thing an auditor is actually checking when they ask how the sign-off was obtained.

   What it uses: Re-authenticated, chained signatures with reason codes

6. 6

   Schedule the effectiveness check now, not later

   A scheduled workflow reads actions whose effectiveness check is due and starts a verification run. This is the step that gets skipped when it depends on somebody remembering. As a schedule it has a run history like any other workflow, and it raises a notification if it stops firing.

   What it uses: Schedule triggers, with alerting on failure and stalled runs

7. 7

   Show the chain on demand

   The deviation, the causes, the actions, who signed what and when the effectiveness check happened are attached to one record with its run history. The inspector follows the chain rather than being handed a folder.

   What it uses: Record history alongside per-step run history

Numbers used above, and where they come from

Every figure on this site is counted from the product itself. Nothing here is a performance or customer claim, because there is no measurement to cite for one.