One rule set, every petrochemical site, numbers that roll up
Across a petrochemical group the interval engine's job is to make a single rule set produce every site's next inspection date, so the numbers roll up. It holds corporate defaults for corrosion rate selection, minimum thickness basis and half-life application, permits governed site overrides where a jurisdiction or licence demands one, and records which rule produced every date.
Sites rarely disagree about the code. They disagree about the inputs the code leaves to the owner-user. One site draws a piping circuit at the unit boundary and another at the line number, so one has twelve condition monitoring locations and the other has two hundred. One sets minimum thickness from the pressure-design calculation, another from nominal minus corrosion allowance, a third from a structural table. One applies the default corrosion rate that API 570 permits for new equipment in similar service, another carries zero until two readings exist. One counts a deferred inspection as compliant because the date field was changed, another counts it as overdue. Every one of those choices is defensible in isolation, and together they make the group-level report meaningless. Standardising is not a matter of copying one site's spreadsheet; it is the work of naming each decision, setting a corporate default, and deciding which sites keep an exception and why.
Source: Based on API 510, API 570 and API 653 interval and remaining-life rules; API RP 574 for piping inspection practice and API RP 578 for material verification; API RP 571 for damage mechanism identification; API RP 580 and API RP 581 for risk-based intervals; API STD 530 and API RP 573 for fired heater tube life assessment; NACE SP0170 for protection of austenitic stainless steels from polythionic acid stress corrosion cracking during shutdown; the National Board Inspection Code and state jurisdictional rules for in-service pressure equipment; ISO 55001 for asset management governance; and OSHA 29 CFR 1910.119(j) for mechanical integrity.
| Decision the code leaves to the owner-user | Typical site-to-site variance | Effect on the derived due date |
|---|---|---|
| Corrosion rate selection | Long-term only, short-term only, or the greater of the two | Up to a threefold change in remaining life from identical readings |
| Minimum thickness basis | Pressure design, structural minimum, or nominal minus corrosion allowance | Moves the numerator, and can shift a due date by a full inspection cycle |
| Circuit and CML definition | Twelve CMLs per unit at one site, two hundred at another | Changes which point controls, and makes any CML-based KPI incomparable |
| Default rate for equipment without history | The API 570 default from similar service, versus zero until two readings exist | A zero rate yields infinite life and drops the asset out of the schedule entirely |
| Deferral treatment | An edited date field, versus a logged deviation with an approver and an expiry | Determines whether the group overdue count means anything at all |
| Units and precision | mpy and inches at one site, mm per year and millimetres at another | Conversion errors survive every review because both numbers look plausible |
Same code, different answers: where the divergence lives
A group integrity manager who asks five sites for their overdue inspection count and gets five numbers that cannot be added is not looking at a reporting problem. The numbers disagree because the underlying calculations disagree, and they disagree because API 510 and API 570 deliberately leave a set of decisions to the owner-user. The codes tell you the interval is the lesser of half the remaining life and a ceiling. They do not tell you which corrosion rate to use, where a circuit begins and ends, how many condition monitoring locations a circuit needs, or what to assume before a component has two readings.
Those decisions accumulate historically rather than deliberately. One site was set up by a contractor who used long-term rates. Another inherited a practice from a joint venture partner. A third rebuilt its programme after an incident and became conservative in ways nobody has revisited in twelve years. Each site's written procedure is internally consistent and passes its own audits. The group number is still fiction.
The consequence is not merely cosmetic. Capital allocation, contractor framework agreements, insurance disclosures and the corporate risk register all consume that rolled-up number. If the site with the loosest rate selection reports the fewest overdue items, the group will keep sending money to the site that is being most careful, which is the exact inversion of what the reporting was built to prevent.
Legitimate local variance versus undocumented drift
Standardising is not the same as flattening. A site in a jurisdiction that adopts the National Board Inspection Code with state amendments may face a mandated external inspection interval shorter than the API 510 ceiling. A site operating under a specific permit condition, an insurer requirement or a consent decree may carry commitments that no corporate rule can override. A site with a documented history of a particular damage mechanism may hold a conservative interval on engineering grounds. All three are correct and none of them should be normalised away.
What separates those from drift is the record. A legitimate variance has an authority behind it: a citation, an approver, a scope, and a date at which it is reviewed. Drift has none of that, and looks identical from a distance. The practical design requirement is therefore that the corporate rule is the default and every departure from it exists as an explicit, attributed override rather than as a differently configured site.
This also solves the political problem, which is usually the harder one. Site integrity engineers resist standardisation because they read it as head office overruling local knowledge. An architecture in which the corporate rule is the baseline and the site can hold an override with a reason gives the local engineer somewhere to put their knowledge, while giving the group a report on how many overrides exist, why, and which have gone unreviewed for years.
Petrochemical damage mechanisms that resist a single default
A corporate default corrosion rate library only works if it is keyed on service, not on site. Petrochemical plants make that plain. Chloride stress corrosion cracking of austenitic stainless under insulation is driven by temperature, chloride availability and coastal or cooling tower drift, so an identical line at two sites genuinely has different susceptibility. Caustic service produces both gouging and stress corrosion cracking with a strong temperature and concentration dependence, and the mitigation is post-weld heat treatment rather than a shorter interval.
Shutdown chemistry adds a mechanism that has nothing to do with operating hours. Austenitic stainless exposed to sulphidic scale forms polythionic acid when it meets air and moisture during a shutdown, and cracks. NACE SP0170 sets out the neutralising wash and purge practices that prevent it. That is an inspection and preservation requirement triggered by a shutdown event, not by a due date, and an interval engine that only understands calendar cycles will never raise it.
Then there are the assets whose life is not a thinning problem at all. Ethylene cracking furnace coils degrade by carburisation, creep and coke-driven overheating, assessed through tube metal temperature history, diametral growth and metallurgical replication rather than through a wall loss trend. Refrigerated ammonia storage sits under API 653 for the tank but under a nitrate stress corrosion cracking regime for the shell welds. Cold box and cryogenic equipment barely corrodes and fails by other routes entirely. A group standard that assumes every asset is a corrosion rate divided into a wall will quietly exclude some of the highest-consequence equipment on the site.
Why the numbers do not roll up, in detail
Take the simplest group metric, percentage of inspections completed on time. It requires four agreed definitions: the population being counted, the event that starts the clock, the event that stops it, and the treatment of approved deferrals. In practice each site has answered those four questions differently and none of them wrote the answer down, so the resulting percentages can differ by twenty points on identical physical performance. A site reporting ninety-four percent and a site reporting seventy-six percent may be doing the same work equally well.
Unit handling is the quiet one. A group with sites in North America and Europe will have mils per year and inches sitting alongside millimetres per year and millimetres, and often a legacy system that stored whichever the technician typed. Conversion is arithmetically trivial and operationally treacherous, because a corrosion rate of 5 in the wrong unit is still a number a reviewer will accept without blinking, and it produces a remaining life wrong by a factor of twenty-five. The rule is that units are a property of the stored value, never of the site, and every display converts on the way out.
Equipment scope is the other. Idle, mothballed and spared equipment, equipment leased to a joint venture, equipment inside a battery limit operated by a third party, equipment that has been physically removed but never retired in the register, and equipment acquired with a plant and never fully catalogued all move the denominator in ways the group cannot see. Standardising the calculation without first standardising the asset register produces a metric that is precise, auditable and still wrong.
A corporate rule set with governed site overrides
The working architecture has four layers. A corporate rule set defines rate selection, minimum thickness basis, half-life application, ceilings, default rates and deferral handling. A service-based library assigns expected damage mechanisms and starting rates by process service, so a caustic line inherits caustic behaviour wherever it sits. A site layer holds overrides, each with a citation, an approver and a review date. An asset layer holds the component-specific exceptions an engineer has justified in writing.
Every derived date should then be able to state its provenance: which rule version produced it, which layer supplied each parameter, which reading drove the rate, and who last touched an override. That provenance is what makes the number defensible to an auditor and, just as importantly, what makes a site engineer willing to trust a date they did not compute themselves.
Rule sets must be versioned with effective dates, and changes must be simulated before they are committed. A corporate decision to move from long-term to greater-of rate selection will shorten thousands of intervals simultaneously. Knowing in advance how many of those land inside an already-frozen turnaround scope, and at which sites, is the difference between a controlled policy change and a year of firefighting.
Rolling out across sites without stalling on site one
The failure mode of multi-site standardisation programmes is that the first site becomes the whole project. Reconciliation work at site one uncovers every undocumented rule in the group, and the programme stops while a committee argues about rate selection. The way through is to separate the rule debate from the deployment: agree a provisional corporate default early, deploy against it, and let every site difference land as an override with a reason. The override register then becomes the agenda for the rule debate, backed by counts instead of opinions.
Sequence matters too. Start with the site that has the cleanest data rather than the largest asset base, because the first deployment is where the reconciliation method is built. Then take the site whose practice differs most, because it will surface the override cases the rule set has to support. The remaining sites are then a repeatable exercise.
Throughout, keep the legacy site system authoritative until reconciliation for that site is signed off. Running both and comparing is not duplicated effort; it is the only evidence that the new engine reproduces the dates your inspectors are already working to, and the only way a site integrity engineer will accept the switch.
What the group gets once the numbers are comparable
The first payoff is a corrosion rate library built from the group's own measurements rather than from published tables. Once every site computes rates the same way against the same service taxonomy, a new caustic circuit at one plant can inherit a starting rate from twenty years of measurement on identical service at three others, instead of an assumption or a textbook figure. That is a materially better default, and it only becomes available once the calculation is common. It also works in reverse: a service whose measured rate at one site sits well outside the group distribution is either a process problem or a measurement problem, and both are worth knowing.
The second is workload visibility. Specialty crews - phased array, tank floor magnetic flux leakage, heater tube creep assessment, rope access, advanced ultrasonic backscatter - are scarce and are normally booked site by site, three months out, in competition with each other. A group schedule computed on one rule set shows inspection load by technique and by quarter across every site a year or more in advance, which is what makes a levelled schedule or a shared framework contract possible instead of five separate scrambles for the same contractor in the same month.
The third is credibility. When a corporate risk register, an insurer submission or a regulator conversation cites an overdue count, that number now has a derivation behind it that survives being questioned line by line. That is worth more than the reporting itself, because it is what lets an integrity function argue for capital on evidence rather than on anecdote, and what stops a single site's data quality problem from discrediting the whole programme.
How to evaluate multi-site interval software
Ask to see the override register, not the dashboard. Any product can render a green compliance donut. The question is whether it can list every place where a site departs from the corporate rule, what authority each departure rests on, and how many have not been reviewed since they were created. If overrides are implemented as per-site configuration rather than as attributed exceptions, the group can never report on them.
Ask for the rule change simulation. Give the vendor a policy change you are actually contemplating and ask for the delta across all sites before commit. Ask what happens to a date computed under rule version three when rule version four takes effect, and whether the historical record still explains the older date.
Ask how the system holds assets that fall outside the thinning model - heater tubes under API STD 530, cracking mechanisms driven by technique, relief devices, and equipment on jurisdictional rather than API intervals - because those are the assets that leak out of a group roll-up first. Atlantis inspection management software is built around the codes and the written programme your own group cites, configured per site with the corporate rule set intact. A scoping consultation with an ASNT Level III is available on request through info@atlantisndt.com.
Why do two sites running the same code produce different due dates?
Because API 510 and API 570 set a framework and leave the parameters to the owner-user. Rate selection, minimum thickness basis, circuit boundaries, CML density, default rates for equipment without history and the treatment of deferrals are all local decisions. Two sites can be fully compliant and still differ by a factor of three on the same vessel. The divergence is in the written procedure and the configuration, not in the code, which is why harmonising spreadsheets never fixes it.
Which differences between sites are legitimate and which are drift?
A jurisdictional requirement is legitimate: some states and provinces impose external or internal intervals through the National Board Inspection Code or a local boiler and pressure vessel act that are shorter than the API ceiling, and an insurer or operating licence can do the same. That is an override with a citation. Drift is an interval that differs because of a decision nobody documented. The engine must be able to tell the two apart on demand, which means every override carries a reason code, an authority and a review date.
Can we change a corporate rule and see the effect before we commit it?
That is the single most useful capability in a multi-site rollout, and the one most often missing. Rule sets should be versioned with effective dates, and a proposed change should run as a simulation across every site, returning the count of assets whose due date moves, by how much, in which direction, and how many land inside an already-frozen turnaround scope. Without that preview, no corporate integrity manager will ever be allowed to change a rule after go-live.
How do fired heater tubes and non-API equipment fit into the roll-up?
They need their own regime inside the same schedule. Cracking furnace and heater tube life is a creep and carburisation problem assessed under API STD 530 and API RP 573, driven by tube metal temperature history and diametral growth rather than by a corrosion rate. If those assets cannot be held in the system they get managed on a side spreadsheet and disappear from the group compliance number, which is exactly where a gap hides.
Why does our on-time inspection percentage not agree between sites?
Almost always because the denominators differ. One site counts pressure vessels, another counts every CML. One excludes idle and mothballed equipment, another includes it. One treats an approved deferral as on time, another treats it as overdue until executed. One measures against the due date, another against the end of the due year. Fixing the metric means defining the population, the clock and the deferral treatment once, centrally, and computing it from source data rather than from site submissions.
How long does it take to reconcile one site onto the corporate rule set?
The data load is the fast part. The slow part is reconciliation: recompute every asset under the corporate rules, compare against the dates the site is currently working to, and explain each difference as either a legitimate local override, a corporate rule the site had not adopted, or an error in the legacy record. Expect the explanation work to dominate, and expect the first unit to take several times longer than the tenth as the rule library stabilises.
Built for any business that runs on operations
Most companies do not fail at their craft. They lose time, margin and goodwill in the gaps between the tools they use to run the place — a quoting spreadsheet that does not talk to the job sheet, a job sheet that does not reach accounts, and a compliance folder nobody can search when a client asks. Atlantis closes those gaps by putting the whole operation on one platform, so information is entered once and everything downstream stays in step.
What you can run on it
- Sales and CRM — leads, quotes, follow-ups and the pipeline that tells you what next month looks like.
- Projects and job costing — plan the work, track the hours and materials against it, and see the margin while the job is still live rather than at final account.
- Field and service teams — dispatch, schedules, mobile capture that works with no signal, and sign-off from site.
- Inventory and purchasing — stock, suppliers, reorder points and goods receipt, joined to the jobs that consume them.
- People — records, qualifications and licences with renewal reminders, timesheets, leave and payroll.
- Quality and documents — procedures and forms under revision control, with the audit trail an inspection or accreditation body actually asks for.
- Accounts — invoicing, expenses, multi-currency and the reporting your accountant stops chasing you for.
Affordable, accessible, fully customizable — and we mean each word
Affordable because the whole suite is included rather than sold to you a module at a time, and because implementation is done by people who have run operations rather than by a chain of subcontractors. Accessible because it runs in a browser and on a phone, works for a small team on day one, and does not need a specialist on staff to keep it alive. Fully customizable because your process is the thing that makes you competitive — the software should bend to it, not the other way round.
Industries we configure for
Service businesses and contractors, manufacturing and fabrication, trading and distribution, laboratories and testing houses, engineering consultancies, construction and facilities, and asset owners across energy, marine, aerospace and infrastructure. Inspection and testing is where we started, and it remains the sector we go deepest in — but the platform underneath is general-purpose, and most of what it does has nothing to do with inspection at all.
What happens when you get in touch
A short conversation, not a sales sequence. We ask how the business runs today and where it hurts, show you the platform doing that work, and send a written quote shaped to your region, your team size and the scope you actually need. No obligation, nothing to install first, and no pressure to decide on the call. Reach out and tell us what you are trying to fix.
Related: business management platform · inspection management software · choosing the right category of software · modules · by industry · asset integrity platform. Book a free consultation.