Corrective Action Program & Clearance/Tagout
🎯 Who this is for: Regulatory/QA and operations leads who own the Corrective Action Program and the safety controls around work — and who need to know exactly which Maximo Nuclear applications carry the CAP loop and the nuclear tagout discipline.
Series: Part 5 of 7 — Maximo for Nuclear on MAS 9 | Read time: 18 minutes
⚖️ Two Things a Nuclear Plant Cannot Get Wrong
There are two disciplines a nuclear plant is judged on constantly: how it learns from problems, and how it controls work safely. The first is the Corrective Action Program. The second is the clearance-and-permit stack. Maximo Nuclear carries both, and this part walks each — then puts them together, because in practice they are one loop.
They are related for a concrete reason. A poorly controlled job creates a condition; the CAP captures and corrects it; the lessons feed operating experience, which shapes the controls on the next job. Miss either half and the loop breaks: a plant that controls work perfectly but never learns repeats its mistakes; a plant that learns but controls work loosely gets hurt before it can learn. Maximo holds both halves in named applications, with one honest exception (OPEX) we will flag when we reach it.
🔁 Condition Reports (Nuc) as the CAP Engine
In Maximo Nuclear, the CAP engine is a single, purpose-built application: Condition Reports (Nuc). This is not a configuration pattern — it is a real, named application, and the reason is instructive.
Condition Reports (Nuc) documents facility non-conformances and drives the full CAP loop. From the source condition, the application links to:
- Evaluation of the reported condition
- Significance classification — how serious the condition is
- Apparent-cause and root-cause analysis
- Corrective actions, tracked as follow-up work orders
That last point is the design decision that makes the whole thing work. Corrective actions are not free-floating to-do items; they are tracked as follow-up work orders. The fix therefore inherits the entire work-management lifecycle — planning, assignment, status, execution, records — and stays connected to the condition report that spawned it.
The full loop, and why significance classification is the hinge
The CAP loop, as it runs in Maximo:
- A condition report is raised for a non-conformance.
- The condition is evaluated and its significance classified.
- Apparent-cause or root-cause analysis is performed as significance dictates.
- Corrective actions are created as follow-up work orders and executed under the work-management lifecycle.
- Effectiveness is reviewed — closing the loop back to the original condition.
Step 2 is the hinge, and it deserves the domain detail. Significance classification is graded — a plant distinguishes a Significant Condition Adverse to Quality (SCAQ), which demands a formal root-cause analysis and an effectiveness review, from a lesser Condition Adverse to Quality (CAQ), which may need only an apparent-cause evaluation, from a minor condition handled by direct corrective action. The classification determines how much rigor the rest of the loop applies. Get the classification wrong and you either burn root-cause effort on trivia or under-investigate a significant condition — which is itself a finding.
<aside>
💡 Key insight: The reason Condition Reports (Nuc) is a genuine, named application — not a configuration pattern like the Maintenance Rule — is that CAP is the Appendix B XVI obligation, with a defined loop: identify, evaluate, classify significance, determine cause, correct, verify effectiveness. That loop is exactly what a regulator or an INPO evaluation examines. A purpose-built CAP engine, with corrective actions tracked as work orders and significance driving the rigor, is what turns "we have a corrective action program" from an assertion into an auditable, evidenced process.
</aside>
For a regulatory lead, this is one of the two or three places an auditor looks first, and the answer is clean: a named CAP engine under Appendix B XVI, with corrective actions living as tracked work orders and significance classification driving the depth of the response.
🧩 A Worked Example: A Packing Leak Through the CAP Loop
Watch the loop run on one condition. The CAP mechanics (SCAQ/CAQ grading, apparent- vs root-cause, effectiveness review) are genuine Appendix B XVI practice; the identifiers are illustrative.
Identification. During a routine round, an operator finds packing leakage on charging pump CHG-1A's outboard seal. A Condition Report (Nuc), CR-2026-0413, is raised against the Assets (Nuc) record for CHG-1A.
Evaluation and classification. The condition is evaluated: the leak is within technical-specification bounds and CHG-1A remains operable, so it is not an immediate operability concern. Significance is classified as a CAQ (condition adverse to quality) — real, but not significant — which routes it to an apparent-cause evaluation rather than a full root cause.
Cause. The apparent-cause evaluation finds the packing was last replaced with a lot that has shown early degradation elsewhere in the fleet — a link surfaced from the Solutions library (below).
Corrective action. A corrective action is created as a follow-up work order to repack the seal with the qualified packing material, planned and scheduled through the normal work-management lifecycle, and isolated for work via a Clearance (the second half of this part). A second, broader corrective action is opened to review the suspect packing lot across similar pumps — tracked, with a Commitment Tracking (Nuc) entry so it cannot be lost.
Effectiveness. After the repack, the seal is monitored; the effectiveness review confirms no recurrence over the following cycle, and CR-2026-0413 closes with its full trail: condition, evaluation, classification, cause, corrective work orders, and effectiveness result.
<aside>
💡 Key insight: The corrective action being a tracked follow-up work order is what keeps this from becoming a spreadsheet of open items. The repack inherits planning, a clearance, sign-on, and a records trail; the fleet-wide review is held by Commitment Tracking so it survives to closeout. A generic EAM captures the repair work order but loses the program around it — the classification, the cause, the effectiveness review, the commitment. The CAP engine keeps all of it as one connected record.
</aside>
📚 Operating Experience Has No Named App
Nuclear plants live and die by operating experience — learning from their own and others' failures. The natural question is whether Maximo ships an OPEX application. Here is the honest answer, consistent with the rest of the series.
OPEX is a partial capability with no named app. It is implemented via Condition Reports (Nuc) plus a reusable Solutions library plus Commitment Tracking (Nuc). The INPO Operating Experience program is a voluntary framework, and Maximo supports it through a combination of applications rather than a dedicated OPEX module.
The Solutions library is the practical heart of it: a reusable store of known problems and their resolutions, so that when a familiar condition recurs, the captured solution can be found and applied. Paired with Condition Reports to capture and Commitment Tracking to ensure follow-through, it is a workable operating-experience mechanism — as the packing-leak example showed, where the suspect-lot link came from a prior captured solution.
<aside>
💡 Key insight: OPEX is a "no named app" capability, so do not name one. "Operating experience is supported through Condition Reports, the Solutions library, and Commitment Tracking" is accurate. "Maximo has an OPEX module" is not. The Solutions library is real and useful — a genuine reuse mechanism — but the OPEX program is assembled from cooperating applications against a voluntary INPO framework, not shipped as a single app. Scope it as configuration-and-reuse and you set the expectation correctly.
</aside>
Commitment Tracking (Nuc) earns its own mention: it ensures regulatory commitments are carried by work orders through to close-out. When a condition report or event generates a commitment — to a regulator, or internally — Commitment Tracking keeps it from being lost, tying it to the work that discharges it. It is the reason the fleet-wide packing review in the example does not evaporate after the immediate repair.
🔒 The Clearance and Permit Stack
Now the safety controls around work. A nuclear plant's isolation and tagout discipline is more rigorous than a typical industrial site's, and Maximo Nuclear reflects that with a dedicated stack of applications rather than a single Lockout/Tagout screen:
| Application | Role |
|---|---|
| Clearances (Nuc) | Nuclear tagout / isolation prior to work or surveillance — richer than core Lockout/Tagout |
| Clearances Kiosk (Nuc) | Shop-floor kiosk tag apply and restore |
| Clearance Groups (Nuc) | Shared tags across related clearances |
| Sign On/Off (Nuc) | Personnel sign-on and sign-off against work |
| Permits (Nuc) | Streamlined permit issuance for common work types |
The lead application is Clearances (Nuc), and the source is explicit that it is richer than core Maximo Lockout/Tagout. It handles nuclear tagout and isolation prior to work or surveillance — the controlled process of placing a system or component in a safe, isolated state before anyone works on it.
The supporting applications complete the model. Clearances Kiosk brings tag apply-and-restore to the shop floor, where the work actually happens. Clearance Groups lets shared tags span related clearances — important when multiple jobs share an isolation boundary. And Sign On/Off tracks personnel signing onto and off cleared work.
🛡️ Why Nuclear Clearances Are Richer
The phrase "richer than core Lockout/Tagout" is worth unpacking, because it is where the nuclear discipline shows. A generic LOTO screen models "energy source isolated, tag applied, worker protected." A nuclear clearance carries more, and the extra structure is not decoration:
- A defined isolation boundary — the specific set of valves, breakers, and dampers whose position defines the safe state, not just "the breaker is off."
- An order of operations — the sequence in which isolation points are established and restored, because doing it out of order can defeat the isolation or damage equipment.
- Position verification and independent verification — critical isolation points are verified, often by a second qualified person, and that verification is recorded.
- Restoration control — the clearance is not lifted until every tag point is restored to its normal position and verified, in the correct sequence.
- Multiple simultaneous holders — several jobs and several people can be protected by, and signed onto, one clearance.
A worked example: isolating a pump for work
Return to CHG-1A from the CAP example. Before the repack work order executes, operations builds a Clearance (Nuc), CLR-2026-1187, to isolate the pump:
| Tag point | Component | Required position | Verification |
|---|---|---|---|
| 1 | CHG-1A suction isolation valve | Closed | Independent |
| 2 | CHG-1A discharge isolation valve | Closed | Independent |
| 3 | CHG-1A breaker | Open, racked out | Independent |
| 4 | CHG-1A min-flow valve | Closed | Single |
Because the shared breaker cubicle also protects a nearby instrument-air job running concurrently, CLR-2026-1187 is linked through a Clearance Group to that job's clearance, so the shared tag is honored by both and neither can restore it while the other is still working. The two repack technicians Sign On to CLR-2026-1187 at the Clearances Kiosk on the shop floor, where the tags were physically applied and logged. When the repack is complete, they sign off, and restoration proceeds in reverse sequence — min-flow, breaker, discharge, suction — each verified before the clearance is cleared.
<aside>
💡 Key insight: The reason nuclear tagout is a stack rather than a single app is that the discipline has multiple moving parts — the clearance and its ordered boundary, the physical tag apply/restore at the point of work, the shared tags across related jobs, and the personnel sign-on. A single Lockout/Tagout screen collapses all of that into one flat state. The nuclear stack keeps them distinct because each is separately auditable, and because a shared isolation boundary across two jobs is a real, dangerous edge case that Clearance Groups exists to handle correctly.
</aside>
📋 Permits: Wrapping Controls Around Work
The last piece is Permits (Nuc), which provides streamlined permit issuance for common work types — the source notes permit types such as heat-stress permits, linked to clearances. A nuclear work package does not just carry a job plan and a schedule; it carries its safety controls — the clearance isolates equipment, the permit authorizes specific work conditions (heat stress, confined space, hot work), and the sign-on records who is on the job. All of it travels with the work in the system of record.
Tie this back to the work package built in Part 3. That package carried a job plan, hold points, and an operability check via Impact Plans. Now add the controls: the clearance isolates it, the permit authorizes the conditions, and Sign On/Off records the people. The package is not "safe to execute" until those controls are in place and recorded.
<aside>
💡 Key insight: Put Parts 3 and 5 together and you have the full anatomy of a nuclear work package: the work order (Part 3), the operability check via Impact Plans (Part 3), the hold points (Part 3), the clearance isolation (this part), the permit and its conditions (this part), and the personnel sign-on (this part). A generic EAM gives you the work order. The nuclear solution gives you the work order plus the controls that make it safe to execute — each a named, auditable application, with only OPEX riding the configuration-and-reuse pattern.
</aside>
🗂️ A Field-and-Status Reference
Illustrative fields and statuses for the CAP and clearance records — names vary by release and configuration, but the shape is what to scope against:
| Record | Key attributes | Representative statuses |
|---|---|---|
| Condition Report (Nuc) | CR number, significance (SCAQ/CAQ/minor), evaluation, cause type, corrective-action WOs | NEW, SCREENED, IN-EVAL, ACTIONS-ASSIGNED, CLOSED |
| Corrective action WO | WONUM, parent CR, work type, effectiveness-review flag | WAPPR, APPR, INPRG, COMP |
| Solution (library) | Symptom, cause, resolution, applicable asset types | ACTIVE, DRAFT |
| Clearance (Nuc) | Clearance number, isolation boundary / tag points, verification, group link | DRAFT, APPROVED, APPLIED, WORK-COMPLETE, RESTORED |
| Sign On/Off (Nuc) | Person, clearance, sign-on time, sign-off time | ON, OFF |
| Permit (Nuc) | Permit type (heat-stress, etc.), linked clearance, conditions | ISSUED, ACTIVE, EXPIRED, CLOSED |
⚠️ Edge Cases That Bite
- Significance mis-classification. Classifying a SCAQ as a CAQ under-investigates a significant condition — a direct finding. Build the classification criteria and a challenge/escalation path so a low classification can be questioned.
- Shared isolation boundary. Two jobs sharing a tag point is the classic tagout hazard. Without a Clearance Group, one crew can restore a tag the other crew is still relying on. Model shared boundaries explicitly, always.
- Sign-on discipline. A clearance protects only the people signed onto it. A technician who works under a clearance without signing on is unprotected and invisible to restoration control. Enforce sign-on at the point of work (the kiosk), not as an afterthought.
- Restoration out of sequence. Restoring tag points in the wrong order can defeat isolation or damage equipment. The clearance must enforce the restoration sequence, not just the application sequence.
- Effectiveness review skipped. For SCAQs, the loop is not closed until effectiveness is reviewed. A CR marked "closed" at corrective-action completion, without an effectiveness review, is an incomplete CAP loop.
- Orphaned commitments. A commitment that is not tied to a work order or tracked in Commitment Tracking can be lost when the immediate condition closes. Bind every commitment to the work that discharges it.
🔧 Troubleshooting the CAP and Clearance Loop
| Symptom | Likely cause | What to do |
|---|---|---|
| Root-cause effort spent on trivial conditions | Over-classification of significance | Calibrate SCAQ/CAQ criteria; grade the response to the significance |
| A significant condition was under-investigated | Under-classification, no challenge path | Add an escalation/challenge step to significance classification |
| A crew was working unprotected under a clearance | Sign-on not enforced at the point of work | Require kiosk sign-on before work; audit sign-on against labor on the WO |
| A shared tag was restored while a crew still needed it | No Clearance Group across the shared boundary | Link the clearances in a Clearance Group; block restore while any holder is on |
| A CR closed without effectiveness confirmed | Effectiveness review not required for the class | Require an effectiveness review for SCAQ before CR closure |
| A commitment disappeared after the fix | Commitment not tracked to a WO | Record it in Commitment Tracking, tied to the discharging work order |
🔄 How CAP and Controls Connect
Step back and the two halves of this part are one loop:
- Work is controlled by Clearances (Nuc), Permits (Nuc), and Sign On/Off — isolation and authorization keep execution safe.
- When something goes wrong — a non-conformance, an event — a Condition Report (Nuc) captures it.
- The CAP evaluates, classifies significance, determines cause, and creates corrective actions as follow-up work orders under Appendix B XVI.
- The lessons are captured in the Solutions library and carried by Commitment Tracking, feeding operating experience back into how the next job is controlled.
That loop — control the work, capture the problem, correct it, learn from it — is the operational heart of nuclear quality assurance. Maximo Nuclear carries every stage in named applications, with OPEX honestly flagged as a configuration-and-reuse pattern.
📋 Practical Notes: Scoping This Honestly
- Name Condition Reports (Nuc) as the CAP engine. It is a real, named application under Appendix B XVI — say so, and specify significance-graded response and effectiveness review.
- Name OPEX as configuration. "OPEX is Condition Reports plus the Solutions library plus Commitment Tracking" is accurate; "an OPEX module" is not.
- Name the clearance stack explicitly. Clearances (Nuc), Clearances Kiosk, Clearance Groups, and Sign On/Off — and require Clearance Groups wherever shared isolation boundaries exist.
- Enforce sign-on at the point of work. Make kiosk sign-on a control, not a courtesy; a clearance protects only who is signed on.
- Wrap the package. Require that clearance, permit, and sign-on travel with the work order so the safety controls are part of the record, not alongside it.
Key Takeaways
- Condition Reports (Nuc) is the CAP engine under 10 CFR 50 Appendix B XVI — non-conformance, evaluation, significance classification (SCAQ/CAQ), cause analysis, corrective action, and effectiveness review.
- Corrective actions are tracked as follow-up work orders, keeping the fix inside the work-management lifecycle and tied to its condition report.
- OPEX has no named app — it is Condition Reports plus a reusable Solutions library plus Commitment Tracking; scope it as configuration and reuse.
- Clearances (Nuc) is richer than core Lockout/Tagout — with an ordered isolation boundary, independent verification, and shared-boundary handling via Clearance Groups, Clearances Kiosk, and Sign On/Off.
- Permits (Nuc) and Sign On/Off wrap the safety controls around the nuclear work package, so clearance, permit, and sign-on travel with the work.
References
- IBM Maximo for Nuclear Power 7.6.1 — Condition Reports application (IBM Documentation)
- IBM Maximo for Nuclear Power 7.6.1 — Solutions application (IBM Documentation)
- Permits in support of work orders (IBM Support)
- 10 CFR 50 Appendix B — Corrective Action (Criterion XVI) (NRC full text)
- Cohesive Solutions — Corrective Action processes with Maximo
Series Navigation
| Previous: | Part 4 — The Maintenance Rule (10 CFR 50.65) in Maximo |
|---|---|
| Next: | Part 6 — The Regulatory Crosswalk |
About TheMaximoGuys: We help Maximo developers and teams navigate the move to MAS 9 with practical, no-hype guidance grounded in how the platform actually behaves.
Published by TheMaximoGuys | July 2026
Venkat Achanta
