Mechanical Integrity Software: What OSHA PSM Requires and What Software Can Actually Evidence
Mechanical integrity is the OSHA Process Safety Management element, 29 CFR 1910.119(j), that requires covered equipment to be inspected and tested to recognised good engineering practice, with deficiencies corrected before continued use. Software cannot supply the programme, but it is what makes compliance evidenceable at audit rather than assertable.
The element has five parts, and only some of them are software-shaped. It requires written procedures for maintaining ongoing integrity, trained maintenance personnel, inspection and testing performed to recognised and generally accepted good engineering practice at a frequency consistent with manufacturer recommendations and prior operating experience, documented results, correction of deficiencies before further use, and quality assurance on new equipment and spare parts. The parts a system can carry are the inspection and testing schedule, the record of what was performed and found, the deficiency register with its ageing and closure evidence, and the demonstration that intervals follow the practice actually cited — normally API 510, 570 or 653 downstream. What it cannot carry is the competence of the people, the adequacy of the procedures, or the decision to run past a due date. Those remain judgement calls the operator owns and an auditor will probe directly.
Source: OSHA 29 CFR 1910.119(j) Process Safety Management, mechanical integrity; API 510, API 570 and API 653 as recognised good engineering practice for fixed equipment; API RP 584 Integrity Operating Windows; API RP 580 and 581 for risk-based inspection; CCPS guidance on asset integrity management.
| 1910.119(j) element | What software can evidence | What stays with the operator |
|---|---|---|
| Written procedures | Version control, approval record, currency against the equipment in scope | Whether the procedure is technically adequate |
| Trained maintenance personnel | Certification register, expiry tracking, scope by method and level | Whether the training produced competence |
| Inspection and testing | Schedule derived from the cited practice, completion record, technique used | Selecting the practice and the technique appropriate to the damage mechanism |
| Documented results | Readings, findings and disposition retained and reproducible | The engineering judgement recorded in the disposition |
| Deficiency correction | Deficiency register, ageing, assignment, closure evidence | The decision to continue operating with a deficiency open |
| Quality assurance | Material and spare-part records tied to equipment | Fabrication and installation control |
Backlog and deferral are what audits actually turn on
In practice, a mechanical integrity finding rarely arises because an inspection was never conceived. It arises because an inspection came due, was deferred, and the deferral has no engineering basis recorded against it. The equipment kept operating, the due date moved, and nothing in the record explains why that was acceptable.
A deferral can be entirely legitimate. Remaining life may support it, the damage mechanism may be slow, a compensating measure may be in place. What makes it defensible is that the reasoning was written down at the time, by someone competent to make it, against data that supported it. What makes it indefensible is a date changed in a planning system.
This is the single most useful thing a system can enforce, and the reason backlog ageing by equipment criticality is worth more than most reporting features. A programme that can produce that view on demand is usually in good shape; one that cannot is usually carrying deferrals nobody has looked at.
Integrity operating windows, and why they get skipped
API RP 584 describes integrity operating windows: the process limits within which the damage mechanisms assumed by the inspection plan remain the ones actually occurring. Exceed them, and the corrosion rate the interval was built on no longer describes the equipment.
They are frequently skipped because they sit between two groups. Operations owns the process variable; integrity owns the consequence; and unless an exceedance raises something an integrity engineer sees, the inspection plan silently stops matching the plant. The mechanism is quiet and the consequence arrives one turnaround later as an unexplained rate change.
Where a system helps is in making the link explicit — an exceedance flagged against the equipment whose plan depends on it, rather than logged in a process historian nobody reviews for integrity purposes. That connection is more valuable than any additional inspection feature.
How Atlantis supports a mechanical integrity programme
Atlantis provides the inspection management and reporting layer: the equipment and circuit register, condition monitoring locations and thickness history, corrosion rate and remaining life, intervals derived against API 510, 570 and 653, certification and calibration tracking, and a deficiency register with ageing and closure evidence. The digital twin layer places that history on the asset geometry so a reviewer can see where the damage is rather than reading coordinates.
Alongside the software, the Level III side of the business writes and qualifies the procedures the programme runs on, authors the written practice governing personnel certification, and performs independent review of contractor inspection data before it becomes the basis for an interval decision. That review is the part most often missing, because it requires someone qualified to judge whether the technique addressed the damage mechanism claimed.
Atlantis is not a PSM auditor and does not sell API 510, 570 or 653 inspector training. Request a consultation to scope a gap review against your own programme.
What an auditor asks, in the order they ask it
The opening question is almost always scope: which equipment is in the covered process, and how was that boundary decided. A programme that cannot produce a defensible equipment list has a problem no amount of inspection quality will offset, because everything downstream is measured against that list.
The second is practice: which recognised and generally accepted good engineering practice governs each equipment class, and where is that choice documented. For fixed equipment in refining and chemicals the answer is normally API 510, API 570 and API 653, but the selection itself is auditable and needs to be written down rather than assumed.
The third is evidence: show me an inspection that was due, and show me what happened. This is where programmes usually come apart — not because inspections were skipped, but because the record cannot connect the due date, the work performed, the result and the disposition into a single reproducible chain.
Why deficiency correction is the element that generates findings
The standard requires deficiencies outside acceptable limits to be corrected before further use, or in a safe and timely manner when necessary means are taken to assure safe operation. That second clause is where judgement lives, and where documentation most often fails to keep up with practice.
Operating with a known deficiency is not automatically a violation. Doing so without a recorded engineering basis, a defined compensating measure and an owner accountable for closure generally is. The distinction is entirely in the record, which is why a deficiency register with ageing, assignment and closure evidence is worth more at audit than any additional inspection capability.
The practical test on your own programme is simple: pull the oldest open deficiency on covered equipment and ask what justifies it still being open. If the answer requires someone to reconstruct the reasoning from memory, the record is not adequate.
Where the NDT technique itself becomes a mechanical integrity issue
Inspection and testing must be appropriate to the damage mechanism, not merely performed on schedule. A thickness grid laid out on a drawing does not detect corrosion under insulation, because that damage concentrates at penetrations, supports and drains rather than distributing evenly. The inspection can be complete, on time, and blind.
API RP 571 exists to close that gap by cataloguing the mechanisms credible for a given service, and API RP 583 does the same specifically for corrosion under insulation. Building the scope from the mechanism forward is what makes a technique defensible when someone asks what it was expected to find.
This is the point at which software stops helping and technical authority starts. Judging whether a technique actually addresses the mechanism claimed requires a qualified reviewer, which is why independent review of contractor data before it becomes the basis for an interval decision is a distinct and frequently missing control.
What does OSHA PSM require for mechanical integrity?
29 CFR 1910.119(j) requires written procedures for maintaining ongoing integrity, trained maintenance personnel, inspection and testing to recognised good engineering practice at an appropriate frequency, documented results, correction of deficiencies before continued use, and quality assurance on new equipment and spare parts.
Which equipment falls under PSM mechanical integrity?
The covered process equipment the standard lists, including pressure vessels and storage tanks, piping systems with their components and supports, relief and vent systems and devices, emergency shutdown systems, controls including monitoring devices and sensors and alarms and interlocks, and pumps. Scope is set by the covered process, not by equipment type alone.
What counts as recognised and generally accepted good engineering practice?
For fixed equipment in refining and chemicals this is normally the API inspection codes — API 510 for pressure vessels, API 570 for piping and API 653 for aboveground storage tanks — together with the applicable ASME construction codes. The operator selects and documents the practice; the choice itself is auditable.
Can software make a plant PSM compliant?
No. Software evidences the inspection schedule, the record of what was performed, the deficiency register and the derivation of intervals from the cited practice. It cannot supply competent personnel, technically adequate procedures, or the judgement behind a decision to keep operating with a deficiency open — which is what an auditor probes.
Why do inspection deferrals cause audit findings?
Because the deferral usually has no engineering basis recorded against it. Deferring can be entirely legitimate when remaining life supports it and the reasoning is written down at the time by someone competent. What fails an audit is a due date moved in a planning system with nothing explaining why that was acceptable.
What is an integrity operating window?
Under API RP 584, the process limits within which the damage mechanisms assumed by the inspection plan remain the ones actually occurring. Operating outside them means the corrosion rate the interval was built on no longer describes the equipment, so an exceedance should raise something an integrity engineer actually sees.
In more detail
RAGAGEP compliance is usually asserted in an MI programme, not documented — a procedure references API 510 or API 653 in general, but nothing in the record shows which specific clause governed a specific inspection decision on a specific piece of equipment. Atlantis ties the RAGAGEP citation to the equipment class and the finding, not to the programme as a whole.
An auditor testing OSHA PSM mechanical integrity does not accept "we follow API codes" as an answer to "why was this interval chosen" — they want the specific clause. A pressure vessel's inspection interval traces to a specific paragraph in API 510; a storage tank's traces to a specific paragraph in API 653; a piping circuit's traces to API 570. When those citations live only in an engineer's head or a procedure document nobody re-reads, the finding record can't reproduce the reasoning, and that gap — not the interval itself — is what generates the audit finding. Atlantis stores the governing clause as an attribute of the equipment class, so every interval decision it generates carries its own citation automatically.
Citing the specific practice, not the programme
Every equipment class in the system carries its governing RAGAGEP reference as data, not as a note in a separate procedure binder: pressure vessels cite API 510, storage tanks cite API 653, piping circuits cite API 570, and each is scoped to the specific clause an interval decision relies on.
When an interval or a repair decision is generated, the citation travels with it into the record — so six months later, when an auditor asks why a specific tank got a specific interval, the answer is retrievable in seconds rather than reconstructed from memory.