Contents
In refining and petrochemicals, fixed equipment rarely fails “on schedule.” Corrosion, process changes, parameter excursions, and defects live their own lives. Yet inspections and much of maintenance still follow a calendar: the date arrives, so we go look. Risk then gets lost between engineering, process, inspection, and audit: assessments scatter across Excel and PDFs, operating signals do not trigger reassessment, and six months later nobody can defend the assumptions.
In this mechanical-integrity pilot we build a different loop: priorities via risk-based inspection (RBI) — probability of failure (PoF) times consequence of failure (CoF). This is not a “ship RBI in one sprint” guide and not a pitch for one “draw the matrix” button. The module is actively in development; the repository is private. Below are field notes: why you need a loop, what parts it has, and which engineering choices already carry the practice.
A short public stack summary is on the RBI portfolio page. A sibling practice note covers handwritten UT forms: different domain, same discipline — the system beats a single tool or screen.
Key takeaways
A calendar without risk creates false coverage. You can close the schedule and still miss a high-risk asset.
RBI is a program, not one matrix screen. You need signal → reassessment → NDE plan → evidence base.
L1 / L2 / L3 answer different questions: enterprise queue, asset card, step-by-step analysis.
Operating modules must trigger reassessment — integrity operating windows (IOW), management of change (MOC), investigations, data quality.
API RP documentation and certification (ICP) prep are product surfaces for a Russian-speaking team, not “a PDF on the side.”
Engineering: extract from the monolith, share one docs package, freeze UI contracts first — then align the backend.
WIP is fine: frontend with mocks, growing tests, API stabilization still ahead.
The job and the cost of error
Without a single integrity program you typically see:
- risk scores that are hard to compare;
- no action queue at enterprise level;
- IOW deviations and site changes that do not always force a recalculation;
- no assumption trail fit for audit;
- English API standards that are painful in daily work;
- ICP exam prep disconnected from the living method.
The cost of a miss is not “awkward UI”; it is a wrong inspection priority: effort lands on quiet assets while disputed ones live longer than they should. So the pilot rejects “pretty risk matrix → export to Excel.” We need a loop where risk is updated and explained.
Why the calendar loses to a loop
A calendar plan is convenient for reporting: date, fact, checkbox. It answers poorly “where do we go today when there are fewer people than assets?” RBI answers through PoF × CoF and an API RP 581-style matrix — but only if inputs, damage mechanisms, and consequences are aligned, not sketched by gut feel.
Calendar and risk are not enemies. The calendar remains the commitment frame. Risk should reorder the queue inside that frame and force off-cycle reassessment when process changes, a defect appears, or an integrity window is breached.
flowchart LR
signal[OpsSignal] --> reassess[RiskReassess]
reassess --> plan[InspectionPlan]
plan --> evidence[AuditEvidence]
evidence --> portfolio[PortfolioQueue]
portfolio --> reassess
Standards are roles, not footer décor
| Standard | Role in the loop |
|---|---|
| API RP 580 | RBI program elements, lifecycle, roles, data |
| API RP 581 | PoF × CoF method, matrix, inspection plan, management-systems factor |
| API RP 571 | Damage mechanism catalog |
| API RP 584 | Integrity operating windows (IOW) |
| API RP 970 | Corrosion systems / corrosion control document |
| API 579 | Fitness-for-service (FFS) |
| API RP 585 | Failure investigations |
| API 653 | Tanks and ICP learning loop |
Listing a standard ≠ adopting it. Adoption starts where the standard binds to an action queue and to reassessment.
Product contour
Four major navigation areas:
- Portfolio — asset risk and action queue at enterprise level.
- Integrity program — operating modules + RBI management.
- Documentation — key API RP translations with search and links.
- Training — academy and ICP practice banks.
Asset levels
L1 — portfolio. Risk and overdue indicators, PoF/CoF matrix, heatmap, filters by unit, equipment type, damage mechanism, risk band. Value: work the risk queue, not the alphabet.
L2 — equipment card. Current risk, mechanism contribution, consequences, analysis history, explainability (“unpack trust” in the result).
L3 — step analysis. Scenarios → criteria → factors / damage mechanisms → PoF and CoF → decision and inspection plan. The result returns to the portfolio and becomes part of the program — not a one-off file.
L3 is where you see why a loop beats a “calculator in chat.” Each step records assumptions: which consequence scenario was chosen, which damage mechanisms are credible, which methodology version applies on site. If steps cannot be replayed, the risk matrix becomes an opinion with nice colours.
In practice we separate calculation from decision. Calculation yields categories and factor contribution. Decision is the inspection plan and what returns to the portfolio as a commitment. Merging them into one “result” field is dangerous: later you cannot tell “the model computed this” from “the analyst decided that.”
Twelve modules — why they sit next to the “calculator”
RBI without an operating loop goes stale fast. The integrity program has two groups.
Operating integrity: damage-mechanism catalog, corrosion systems, IOW, FFS, investigations.
RBI management: MOC, stale analyses, data quality, CoF scenarios, methodology, audit, analytics.
The point is not “twelve screens.” The point is closed triggers: an IOW excursion, an MOC change, or an investigation lesson must enter the “recalculate” queue, or the risk portfolio quietly rots.
Data quality deserves a special callout. High risk with poor inputs and high risk with good inputs are different management decisions. The data-quality module separates “inspect” from “collect facts first.”
Next to it sits audit: not only compute risk, but package assumptions and data provenance. Without that the program fails external review and the internal fight “why is this vessel red.”
Another underrated loop is stale analyses. Even a perfect L3 ages: process changed, methodology updated, validity expired. A “recalculate” queue keeps the portfolio alive. Otherwise a year later you stare at a pretty but historical risk picture.
Documentation and academy as product loops
An English PDF of a standard does not survive daily shift and analyst work. In the pilot, documentation is its own loop: translations of key API RPs, TOC, search, cross-links, switch to the original. Engineering-wise it lives in a shared package: one edit source for in-app /docs and a separate reader app (web and Windows installer). Rule one: do not copy markdown between apps, or translations diverge within a week.
The academy closes skills: learning tracks and ICP practice banks (including open/closed-book modes for some standards). Do not confuse “prep bank” with “official exam,” and do not publish question text. Publicly it is enough to say: prep is tied to the same method as the working loop.
The “document ↔ training ↔ working analysis” link sounds obvious, yet on sites it often breaks: the standard lives in one place, the course in another, and risk is scored “as we always did.” In the pilot we deliberately pull these three loops into one product even while content is still growing.
Engineering choices that already paid off
Extract from the monolith. The module lives in its own repo with its own build, tests, and releases. Costlier at the start; cheaper when integrity grows faster than the parent app.
Frontend-first. UI behavior and contracts stabilize before backend alignment: response schemas (including zod) change with entities. Default mocks let analyst scenarios run without waiting for every API endpoint.
Docs as a package. Search and TOC are built by scripts; rasters are compressed for offline distribution. Boring engineering — and exactly what makes a standard usable in the field.
The public stack can be named without customer detail: React, Ant Design, TanStack Query, visualizations (d3 / flow diagrams), documentation search, TypeScript. Not a fashion kit — a consequence of dense portfolio tables, explainable L3 steps, and long standard documents.
What is still open
- Backend alignment to already frozen UI contracts.
- Test coverage growth and demo/prod data-mode stabilization.
- Methodology and site-policy calibration on real asset volumes.
- Academy depth and discipline for updating question banks.
- Portfolio visualization performance on large sets.
Common mistakes
Buy a “5×5 matrix” and call it RBI. Without data, damage mechanisms, and reassessment triggers it is a poster.
Keep IOW and MOC in separate journals. If the signal never reaches the risk queue, the program is dead.
Score risk without data quality. You get confidence without grounds.
Translate standards as a dumped file with no search or links. In a month nobody finds the paragraph they need.
Promise a full backend before analyst scenarios stabilize. Freeze L3 step contracts and portfolio statuses first.
What to try today
- Write down where your “risk truth” lives today (Excel, PDF, expert memory) and the cost of a wrong priority.
- Separate L1 / L2 / L3 questions — do not mix the enterprise portfolio with a single vessel’s step analysis.
- Pick one operating trigger (IOW or MOC) and walk it to reassessment on paper or in a prototype.
- Check whether an engineer can find the needed API RP 580/581 fragment in your knowledge base in 30 seconds.
FAQ
Is this production-ready?
The pilot covers a coherent product/UI loop; the module is still in active development. Copy the loop discipline — do not wait for boxed RBI from a blog post.
How is this different from risk math in Excel?
Excel does not hold an enterprise queue, reassessment triggers, an audit trail, or linked docs/training. The matrix is one artifact of the loop, not the whole loop.
Do we need all twelve modules at once?
No. Start with the portfolio, one L3 scenario, and one operating trigger. Grow the rest when the pain appears.
Where is the public project description?
On the RBI portfolio page. Source code and site data stay private.
How does this relate to the UT forms article?
That piece is field-form recognition and the cost of millimetre errors. This one is the inspection-priority program. Both sit in the practice series: an industrial loop beats a lonely tool.
Closing
Worth a team’s attention on similar assets? Yes — if you will build a risk loop, not paint a calendar and a matrix separately. The pilot already assembles portfolio, step analysis, integrity modules, API RP docs, and training. Ahead: backend, volume calibration, and the habit of living in the risk queue.
The practice lesson: the calendar records that you looked; risk should decide what to look at first.