{"slug":"/standards/api-584","title":"API RP 584 Integrity Operating Windows: IOW Requirements","description":"API RP 584 integrity operating windows: critical limits need action within the shift, standard limits within days, and every IOW needs a lower bound.","h1":"API RP 584: Integrity Operating Windows That Actually Get Acted On","answer":"API RP 584 defines integrity operating windows, the process limits set inside the safe operating envelope to keep equipment damage rates predictable. It classifies each limit as critical, standard or informational, requires both upper and lower bounds, and demands a named owner, a defined response time and an escalation path for every exceedance. The limit values come from the corrosion control document, not from API RP 584.","expansion":"API RP 584 exists because most fixed equipment failures are not surprises in the metallurgy; they are process excursions nobody classified. The recommended practice supplies a structure rather than a table of numbers. Identify the credible damage mechanisms on each circuit, find the process variables that drive their rate, set limits on those variables that sit inside the safe operating envelope, classify every limit by the urgency of exceeding it, and name the person accountable for the response. Critical limits change damage rate fast enough that operations must act on shift. Standard limits accumulate damage over weeks and drive an inspection or engineering response. Informational limits exist to trend, refine and feed the next reassessment. The actual values come from the corrosion control document, the damage mechanism literature and the unit inspection history. What API RP 584 supplies is the discipline that turns those values into something an operator can act on.","source":"Sources: API RP 584 Integrity Operating Windows; API RP 970 Corrosion Control Documents; API RP 571 Damage Mechanisms Affecting Fixed Equipment in the Refining Industry; API RP 580 and API RP 581 Risk-Based Inspection; API RP 932-B (overhead and sour water systems); API RP 941 (Nelson curves for high temperature hydrogen attack); API RP 945 (amine unit corrosion); API 510, API 570 and API 653 inspection codes; OSHA 29 CFR 1910.119 Process Safety Management.","table":{"caption":"API RP 584 limit classification, expected response and the evidence an auditor asks for","columns":["IOW type","What an exceedance means","Expected response","Evidence that the window is real"],"rows":[["Critical","Damage rate accelerates fast enough that continued operation can consume remaining life or challenge containment","Operator action within the shift, with documented escalation to the unit engineer and the inspection group","Control system alarm set at the limit, alarm rationalisation record, shift log entry, closure record"],["Standard","Damage accumulates over days to weeks; the circuit is not immediately at risk but the inspection plan assumption is broken","Engineering and inspection review inside an agreed period, typically days, with the corrosion rate reassessed","Trend chart with the limit drawn on it, exceedance report, revised corrosion rate in the data management system"],["Informational","A parameter has moved outside its expected band with no direct short term integrity consequence","Log and trend; feeds the periodic IOW and corrosion control document review","Laboratory trending record, periodic review minutes, revision history on the corrosion control document"],["Lower limit, any classification","A variable has fallen below the value that keeps a mechanism suppressed, for example wash water rate, velocity, inhibitor dose or margin above water dew point","The response assigned to its classification; a lower limit is not a softer limit","Both bounds present in the IOW register rather than a single maximum"],["No limit assigned","A credible damage mechanism is running with no process variable monitored against it","Gap closure action raised at the corrosion control document review","Traceability matrix linking every credible mechanism to at least one monitored variable"]],"note":"Classification drives response time, not the size of the number. A small excursion on a critical limit outranks a large excursion on an informational one."},"facets":[{"q":"What is the difference between an integrity operating window and a safe operating limit?","a":"A safe operating limit protects against immediate loss of containment and is a process safety parameter; exceeding it can fail equipment now. An integrity operating window sits inside that envelope and protects the metal from accelerated degradation over time. The two are set by different disciplines from different inputs, and the IOW is almost always the tighter of the pair. Merging them into one register is the most common structural error in an IOW programme, and it always loosens the integrity limits."},{"q":"Does API RP 584 tell me what my IOW limits should be?","a":"No. API RP 584 is a method, not a data source. It describes how to derive, classify, communicate, monitor and revise limits, and it publishes no values of its own. The numbers come from the corrosion control document for the unit, from damage mechanism references such as API RP 571, from service specific documents including API RP 932-B, API RP 941 and API RP 945, and from the operating and inspection history of the actual equipment in front of you."},{"q":"Why does API RP 584 insist on lower limits as well as upper limits?","a":"Because several mechanisms are driven by a variable falling rather than rising. Overhead temperature dropping toward the calculated water dew point starts aqueous condensation and hydrochloric acid attack. Velocity falling below the threshold that keeps solids suspended starts under deposit corrosion. Wash water, neutraliser or filming inhibitor rates falling remove the suppression the circuit was designed around. A register carrying only maximum values is blind to an entire class of excursion."},{"q":"Who owns an integrity operating window once it is set?","a":"API RP 584 expects a named accountable owner for every limit, normally the operations supervisor or unit engineer for the response and the inspection or materials engineer for the technical basis. Ownership has to survive shift change, reorganisation and staff turnover, which is why the practice pushes limits into the control system, the shift handover and the inspection data management system instead of leaving them inside an engineering report nobody opens."},{"q":"How often should integrity operating windows be reviewed?","a":"On a defined cycle and on trigger. The cycle normally aligns with the corrosion control document and the risk based inspection reassessment. The triggers matter more: a crude slate or feedstock change, a treatment chemical change, a revamp or capacity increase, an unexplained inspection finding, a leak, and any management of change touching a monitored variable. A window never revisited after a feed change has stopped describing the unit it governs."},{"q":"What does an auditor look for when testing an IOW programme?","a":"Traceability in both directions. From every credible damage mechanism to a monitored variable carrying a limit, and from every exceedance back to a documented response with a date and a signature. Auditors also test whether critical limits are genuinely alarmed, whether operators can describe what they do when one is breached, and whether the last several exceedances produced any recorded engineering decision at all."}],"sections":[{"heading":"What API RP 584 covers, and what it deliberately leaves out","paragraphs":["API RP 584 addresses fixed equipment in refining, petrochemical and chemical service: piping circuits, pressure vessels, fired heaters, exchangers and the process conditions that govern how fast they degrade. Its subject is the operating envelope rather than the hardware. It sets out how an owner operator derives limits on temperature, pressure, flow, velocity, pH, chloride, ammonium bisulphide concentration, hydrogen partial pressure, water content, wash rates and injection rates, and how those limits reach the people who actually move the levers on the console.","The exclusions matter as much as the scope. API RP 584 is not a design document and establishes no allowable stresses. It does not replace the safe operating limits required under process safety management, which exist to prevent immediate loss of containment rather than to control degradation rate. It does not identify damage mechanisms, which is the work of API RP 571 and the unit corrosion control document. It does not set inspection intervals, which remain governed by API 510, API 570, API 653 and the risk based inspection assessment. And it publishes no limit values of its own.","That last exclusion is where most implementation efforts stall. Teams open the document expecting a lookup table and find a methodology instead. Every value has to be engineered for the specific circuit, its metallurgy, its service and its history, which is exactly the work that an [ASNT Level III consulting](/consulting) engagement or a corrosion and materials specialist exists to do."]},{"heading":"Critical, standard and informational: the classification that decides response time","paragraphs":["API RP 584 classifies limits by the urgency and consequence of exceeding them. A critical limit is one where continued operation outside the window drives damage at a rate that can consume remaining life or challenge containment within a short period, so the response belongs to the console operator on shift. A standard limit is one where damage accumulates over days or weeks, so the response is an engineering and inspection review inside an agreed period. An informational limit carries no direct short term integrity consequence but is trended because it refines the corrosion rate model that the inspection plan rests on.","The classification is about response time, not about how large or alarming the number looks. A five degree excursion on a critical high temperature limit in a sulphidation circuit outranks a wide swing on an informational laboratory parameter. Programmes that classify by apparent severity end up with critical alarms that operators learn to acknowledge and dismiss, which is materially worse than having no alarm at all, because it manufactures a record of compliance around a signal everyone ignores.","A useful test on any existing register: for every limit marked critical, can the shift team state without opening a document what they must do in the first thirty minutes? If they cannot, that limit is not critical in any operational sense, whatever the spreadsheet column says. Either the classification is wrong or the response has never been communicated, and both are findable in an audit."]},{"heading":"Upper and lower bounds: the requirement most registers fail","paragraphs":["API RP 584 expects limits to be bidirectional wherever the underlying mechanism is bidirectional, and a large share of the mechanisms that actually cause leaks are driven by a variable falling. Crude unit overhead systems are the classic illustration. The operative limit is not a maximum temperature but a minimum: the tower top or condenser inlet temperature must remain above the calculated water dew point by a deliberate margin, commonly set in the region of fifteen to twenty five degrees Fahrenheit, or aqueous hydrochloric acid condenses and the local corrosion rate steps up by an order of magnitude.","The same logic runs across the plant. Velocity below a threshold lets solids settle and under deposit corrosion begin; velocity above a threshold in rich amine or ammonium bisulphide service produces erosion corrosion, so both bounds are real. Wash water rate, neutraliser rate and filming inhibitor dose each have a minimum below which the suppression the circuit relies on is simply absent. Sour water and hydroprocessing effluent systems carry both a concentration limit on ammonium bisulphide and a velocity limit that tightens as that concentration rises.","Reviewing an existing register purely for missing lower bounds is one of the fastest value adding exercises available on a mature unit, and it usually takes about a day per unit with the corrosion control document open alongside. It also tends to expose limits inherited wholesale from a sister plant with different metallurgy and a different feed, which is a separate and considerably worse problem."]},{"heading":"Where the numbers come from: mechanism first, operating comfort never","paragraphs":["Every defensible integrity operating window traces to a damage mechanism and a documented technical basis. Hydrogen partial pressure and temperature limits in hydroprocessing trace to the Nelson curves in API RP 941 for high temperature hydrogen attack. High temperature sulphidation limits trace to sulphidation rate data and the sulphur content of the stream. Ammonium bisulphide concentration and velocity limits trace to API RP 932-B. Amine velocity and temperature limits trace to API RP 945. Controls on polythionic acid stress corrosion cracking trace to the neutralisation practice applied during shutdown.","What a window must never trace to is operator comfort or historical operating range. A limit set at last year average plus two standard deviations describes how the unit has been run; it says nothing about the point at which the metal starts to suffer. Auditors ask for the basis, and the honest answer across a large fraction of legacy registers is that the person who set it has retired and the calculation file has been lost.","Recording the basis beside the limit is what lets the register survive people leaving. In practice the corrosion control document holds the mechanism, the circuit and the justification, while the IOW register holds the value, the classification and the owner, with a hard link between the two. When that link exists only in one engineer memory, the first significant feedstock change quietly invalidates the whole set and nobody notices."]},{"heading":"Monitoring, alarms and the accountability chain","paragraphs":["A limit that is not monitored is not a window, it is an opinion. API RP 584 forces owners to decide, for each limit, how the variable is measured, how often, by whom, and where the result lands. Continuously measured variables such as temperature, pressure and flow can be alarmed in the control system, and critical limits generally should be, subject to alarm rationalisation so the operator is not buried under nuisance alarms. Laboratory variables such as chloride, iron, pH and ammonium bisulphide are sampled on a set frequency and belong in a trending system with the limit drawn on the chart, not buried inside a monthly report.","The accountability chain is the part that decays first. Each limit needs a named response owner and a named technical owner, and both roles must survive a reorganisation. When an exceedance occurs, the record has to show who was notified, what decision was taken and when. In practice that record only exists reliably when it is captured in the same system that holds the thickness and inspection history, which is the argument for keeping exceedances inside an [inspection data management system](/inspection-data-management-system) rather than in a mailbox.","For sites operating under process safety management, the exceedance record is also mechanical integrity evidence and is routinely requested during compliance audits. Sites holding that evidence in a controlled system rather than in personal spreadsheets find the audit dramatically shorter, which is one reason IOW tracking increasingly sits inside [mechanical integrity software](/mechanical-integrity-software) alongside the inspection plan it protects."]},{"heading":"Exceedance response: what the procedure must actually say","paragraphs":["The weakest sentence in most IOW procedures is the instruction to notify engineering. It defines no timescale, no decision and no closure test. API RP 584 expects the response to be specific: what the operator does immediately, who is informed within what period, what technical assessment is triggered, what evidence closes the exceedance, and what changes if the excursion repeats.","A workable definition for a critical limit reads roughly as follows. Return the variable inside the window or reduce rate. Log the excursion with start time, peak value and duration. Notify the unit engineer and the inspection group within the shift. The inspection engineer then assesses whether the assumed corrosion rate for the affected circuit still holds; if it does not, the next examination is advanced and the circuit corrosion rate is revised in the data management system. The exceedance closes only when that assessment is recorded, not when the variable returns to normal.","Duration and magnitude both matter and should be captured together. Ten minutes above a sulphidation limit is a different event from ten days at the same value, and the assessment that follows should be proportionate to the exposure. Registers that record only a binary breach flag destroy the information an engineer needs to make that judgement later, and they make it impossible to argue the case either way at the next reassessment."]},{"heading":"The misreadings that produce audit findings","paragraphs":["Four findings recur across sites. The first is conflation of integrity operating windows with safe operating limits, producing a single register in which the IOW values are simply the process safety limits, which are always looser. The result is a programme reporting full compliance while circuits corrode inside the window. The second is upper bounds only, which leaves dew point margin, minimum velocity and every suppression mechanism uncovered.","The third is orphan limits: numbers with no traceable mechanism, usually inherited from a sister site or a vendor recommendation, that nobody can justify and nobody is willing to change. The fourth, and the most consequential in practice, is exceedances that are logged but never assessed. An auditor who reads a year of exceedance records and finds no corresponding change to any corrosion rate, examination date or engineering assessment has found a programme generating paper rather than protection, and that finding is difficult to argue with.","A fifth appears less often in guidance but constantly in reality: the register that passes through a management of change untouched. A new feedstock, a revamped overhead, a different treatment chemical or a capacity increase all move the technical basis, so the management of change procedure should explicitly call for IOW review. Where it does not, the register drifts out of step with the plant one project at a time."]},{"heading":"How IOWs interact with risk based inspection and inspection planning","paragraphs":["API RP 584 sits inside a family of documents. API RP 571 describes what can go wrong. API RP 970 collects the credible mechanisms and their controls into a corrosion control document for each unit and circuit. API RP 584 sets the process limits that hold those controls in place. API RP 580 and API RP 581 convert the resulting confidence into inspection scope and interval, and API 510, API 570 and API 653 govern the examinations themselves. Remove the IOW layer and risk based inspection is resting on an assumption of stable operation that nobody is testing.","That linkage runs both ways, and it is where the programme earns its keep. Sustained operation inside the windows supports the corrosion rates the risk assessment used, which supports the interval that was granted. Repeated excursions do the opposite: they invalidate the assumption, and the correct response is to advance examinations rather than to argue with the number. Writing that reasoning down is what turns an inspection interval into a defensible position instead of a preference.","If your unit has a corrosion control document but no windows, or windows with no traceable basis, the gap usually closes faster with a structured review than with a rewrite from scratch. To have that reviewed by a Level III with refinery fixed equipment experience, [request a consultation](/contact) and we will scope it against the corrosion control documents you already hold."]},{"heading":"Setting an IOW limit from operating comfort instead of the damage mechanism","paragraphs":["The most common defect in an integrity operating window is not a missing limit — most programmes have limits — it is a limit derived from where the unit has historically operated comfortably rather than from the point at which a credible damage mechanism actually accelerates. A limit set at the edge of comfortable operating history looks defensible because the plant has run there before without incident, but it says nothing about the corrosion or cracking kinetics the window is supposed to be protecting against, and it can sit well inside the region where a mechanism is already accelerating without anyone having crossed a documented threshold.","This gap is invisible under normal operation and becomes visible only in retrospect, typically after an inspection finds damage inconsistent with the operating history the IOW register would have suggested was benign. The corrosion or cracking mechanism does not check the plant's operating comfort zone before it accelerates; it responds to temperature, velocity, chemistry and time, and an IOW limit that was never derived from those variables is a historical observation wearing the appearance of an engineering limit.","A defensible IOW register documents, for each limit, the specific damage mechanism it constrains and the technical basis — typically drawn from API RP 571 mechanism data or corrosion-rate modelling for the specific service — rather than citing historical operating range alone. An auditor testing an IOW programme asks for that derivation explicitly, and its absence is one of the more common findings in integrity operating window reviews."]}],"faq":[{"q":"Is API RP 584 mandatory?","a":"API RP 584 is a recommended practice, not a regulation, so it is not mandatory in itself. It becomes effectively binding in two ways: when a jurisdiction, insurer or corporate standard invokes it, and when an owner cites it as the basis of the mechanical integrity programme, at which point auditors test conformance against what the site says it does. Under OSHA process safety management the underlying obligation is to establish and document safe upper and lower operating limits and to address deviations, and API RP 584 is the recognised route to satisfying the integrity half of that duty."},{"q":"How many integrity operating windows should a process unit have?","a":"Enough to cover every credible damage mechanism with at least one monitored variable, and no more than the site can maintain. Typical refinery units land in the tens rather than the hundreds. Registers running to several hundred limits usually contain the same parameter duplicated across circuits plus informational entries that should have been trended rather than alarmed, and they degrade quickly because nobody can keep them current. Coverage is measured by mechanism, never by count."},{"q":"Can integrity operating windows be built into the control system?","a":"Critical limits generally should be, because the response belongs to the operator on shift and the control system is where operators work. This has to go through alarm rationalisation so that critical IOW alarms are not lost inside a flood of nuisance alarms. Standard and informational limits usually sit better in a trending or inspection data management system with the limit plotted on the chart, because their response is an engineering review rather than an immediate operating action."},{"q":"What is the relationship between API RP 584 and API RP 970?","a":"API RP 970 governs the corrosion control document, which records the damage mechanisms credible for each circuit and the controls that manage them. API RP 584 takes the process variables identified there and turns them into classified, owned, monitored limits. In practice the two are built together. A corrosion control document with no windows leaves its controls unmonitored, and windows with no corrosion control document behind them have no traceable technical basis to defend."},{"q":"How quickly should a critical IOW exceedance be closed out?","a":"The immediate operating response belongs to the shift. The technical assessment that closes the exceedance should follow within a period defined in your own procedure, commonly the same or next working day for a critical limit and a few working days for a standard one. What matters more than the exact figure is that the period is written down, is realistic for your staffing level, and is actually met. A growing backlog of unclosed exceedances is the single most reliable indicator of a programme that has stopped functioning."}]}