A pressure equipment integrity report should tell the owner what decision is supported, for which equipment and operating case, under which limitations, and what must happen next. It is not simply an inspection summary, a calculation printout or a collection of appendices.
The report should connect equipment identity, traceable evidence, inspection coverage, engineering assumptions, uncertainty, conclusions, operating limits, actions and approvals. A technically detailed document can still fail if the decision cannot be traced backward to evidence and forward to an executable owner action.
Key Takeaways
- A strong integrity report links every major conclusion to evidence, assumptions, limitations and an owner action.
- An NDT report records an examination; an integrity report interprets relevant evidence within a broader decision basis.
- Equipment identity, scope, exclusions and the governing basis must be clear before calculations can be relied upon.
- Inspection coverage and uninspected areas must remain visible so absence of findings is not overstated.
- Remaining life, operating limits and validity statements need a defined future operating case and reassessment triggers.
- Recommendations become actionable only when priority, owner, due date and closure evidence are assigned.
- The approved revision, technical review and owner acceptance must be unambiguous.
The Report Must Support a Decision—not Only Record an Inspection
The central purpose of an integrity report is to support a controlled equipment decision. The owner should be able to identify the conclusion, the operating conditions it assumes, the evidence behind it, the limitations that remain and the next required actions without reconstructing the logic from hundreds of pages.
The exact name of the document varies. It may be called an integrity assessment report, FFS report, engineering assessment report or another owner-defined title. There is no single universal template that fits every pressure-equipment assessment. The applicable code, jurisdiction, owner procedure, damage mechanism and decision scope determine the exact content and approval route.
ASME FFS-1 addresses the present integrity and projected remaining life of damaged equipment. API 510 provides an in-service inspection, rating, repair and alteration framework for pressure vessels. Neither public summary creates a universal report template, and neither removes the need to confirm the applicable edition and project requirements.
NWE’s Fitness-for-Service service is the primary route where damage or degradation must be converted into an engineering decision.
Integrity Report vs NDT Report, FFS Package and Examination Report
These documents may support the same asset decision, but they answer different questions. Depending on the project and jurisdiction, they may remain separate controlled documents rather than one combined report.
| Document | Primary question | Typical content | What it does not automatically prove |
| NDT report | What was examined, where, how and what indications were found? | Equipment reference, method, procedure, locations, extent, results, acceptance reference and limitations | Continued fitness for service outside the examination and stated criteria |
| FFS calculation / assessment package | Is a defined flaw or degraded condition acceptable for a stated operating case? | Inputs, damage model, calculations, assumptions, sensitivity, margins and remaining-life basis | That all facility risks, inspections or owner actions are controlled |
| Statutory or competent-person examination report | What did the required examination find and what action is legally or procedurally required? | Scope under the written scheme, findings, repairs or danger notifications and examination status | A universal FFS conclusion or owner-wide integrity strategy |
| Pressure equipment integrity report | What decision is supported, under what conditions, and what must happen next? | Identity, evidence register, condition, assessment basis, decision, limits, actions, reassessment and approvals | Automatic regulatory acceptance or a guarantee of future performance |
| Vendor / manufacturing dossier | Was design, fabrication, materials, welding, NDT and testing documented for manufacture and handover? | Design and manufacturing records, certificates, procedures, tests and release documentation | Current in-service condition after years of operation and change |
For the examination-level questions inside an NDT record, use NWE’s guide to reading an NDT report. For fabrication and handover completeness, see pressure equipment documentation review.
Decision–Evidence–Action Report Architecture
A decision-ready report can be reviewed through eight layers. This is an owner-facing architecture, not a mandatory API or ASME table of contents. The exact sections, signatures and retention requirements must be verified against the applicable edition, jurisdiction and owner procedure.
| Layer | Core question | Minimum visible output | Common failure |
| 1. Identity & Scope | Which equipment, condition, decision and exclusions are covered? | Tag/serial/location, report revision, scope, exclusions, assessment date and future case | Wrong asset, hidden exclusion or ambiguous boundary |
| 2. Governing Basis | Which code, standard, owner procedure and jurisdiction apply? | Applicable basis, edition confirmation, hierarchy and approved deviations | Generic “to API/ASME” wording without project basis |
| 3. Evidence Register | What data were used and where did they come from? | Source, date, revision, owner, traceability and confidence | Values copied without provenance |
| 4. Inspection & Condition | What was examined, what was found and what was not covered? | Method, locations, coverage, findings, maps, limitations and data-quality note | No indication treated as no damage everywhere |
| 5. Engineering Assessment | How were findings interpreted? | Damage basis, method, inputs, assumptions, calculations, sensitivity and model limits | Software output without engineering reasoning |
| 6. Decision & Validity | What may the owner do, under which conditions and for how long? | Fitness statement, operating limits, future duty, validity period and invalidation triggers | Fit/unfit statement without conditions |
| 7. Actions & Reassessment | What happens next? | Actions, priority, owner, due date, monitoring, reassessment trigger and closure evidence | Recommendations without implementation path |
| 8. Approval & Control | Who reviewed and accepted the report, and which revision is current? | Author, checker, approver, owner acceptance, revision log and appendices register | Unsigned or superseded report used operationally |
Equipment Identity, Scope and Governing Basis
The report must lock the asset and decision boundary before presenting results. At minimum, identify the equipment tag, serial or unique asset ID, location, service, relevant component, current configuration, report revision and the condition being assessed.
Scope should state what is included, what is excluded and why. If only one shell course, nozzle, weld, corrosion circuit or damage location is assessed, the conclusion should not read as though the entire vessel or system has been cleared. A short scope statement prevents the most damaging form of report ambiguity: a technically correct conclusion applied outside its boundary.
The governing basis should identify the assessment method, applicable code or standard, owner procedure, jurisdictional context, project specification and any approved deviations. Avoid generic wording such as “assessed to API/ASME” without identifying what document applies and how the hierarchy was resolved. The exact edition must be confirmed against the project basis.
Where equipment identity, current configuration or records are incomplete, the report should not hide the gap inside an assumption. The affected decision may need records reconstruction or targeted verification before assessment.
Input Data and Traceability
Every decision-critical input should have provenance: a visible record of where it came from, when it was created, which revision was used, who owns it and how confident the team is that it applies to the assessed equipment. Provenance makes a value reviewable and updateable; it is more than listing a filename in an appendix.
A source register should cover the data that can change the conclusion. Depending on scope, this may include drawings, material records, dimensions, design conditions, operating history, excursions, repairs, inspection reports, raw data, process chemistry, loads and the proposed future operating case.
| Input / evidence | Source and revision | Why it matters | Confidence / action |
| Equipment identity and configuration | Asset register, P&ID, as-built drawing, field verification | Confirms that records and calculations refer to the correct field item | Verified / reconcile mismatch |
| Materials and fabrication | Certificates, drawings, weld records, justified field evidence | Influences allowable basis, damage susceptibility and assessment inputs | Verified / bounded / unresolved |
| Operating history | Historian, logs, MOC, incidents and process review | Connects damage mechanisms and rates to actual service | Current / incomplete / gap action |
| Inspection condition data | Report, raw data, maps, images and location references | Defines flaw size, extent, progression and evidence quality | Assessment-ready / limited / repeat required |
| Future operating case | Pressure, temperature, service, cycles, duration and safeguards | Defines what the decision is expected to support | Approved / provisional / not defined |
| Engineering assumptions | Calculation note and reviewer rationale | Shows how gaps or modelling choices affect the conclusion | Accepted / sensitivity required / close gap |
If a critical value cannot be traced, mark it as unresolved or controlled rather than silently replacing it with a default. A large calculation package cannot compensate for an unidentified or unverified input.
The report should also distinguish evidence that existed before the assessment from information generated during the work. This matters when a field measurement, revised drawing or engineering assumption becomes part of the decision basis. The revision and acceptance status of the new evidence should be clear so it can be reused, challenged or updated without confusing it with the original record.
Inspection Coverage, Findings and Uncertainty
The report should make the inspection boundary visible. State the method, procedure, locations, extent, surface or volume examined, access constraints, no-read areas, data-quality issues and the relationship between the method and the expected damage morphology.
Findings should connect to locations and evidence that another reviewer can reconstruct. Summaries should distinguish measured values, interpreted damage, accepted indications, rejected data and areas that were not examined. “No relevant indication found” applies only to the stated method and coverage; it does not prove that damage is absent elsewhere.
Uncertainty should be tied to decision impact. Explain whether a limitation could change defect dimensions, degradation rate, damage-mechanism selection, remaining-life projection or inspection scope. Where uncertainty is material, define sensitivity, a bounding treatment or a closure action.
NWE’s In-Service Inspection service can support evidence gathering where targeted field data are required. The engineering conclusion remains a separate scope that should state how those data were used.
Engineering Method, Calculations and Assumptions
The report should explain how evidence was converted into a conclusion. It does not need to reproduce every calculation in the executive section, but it must identify the damage mechanism, selected method, critical inputs, assumptions, model limitations and sensitivity of the result.
Calculation summaries should show the controlling result and why it controls. Software screenshots and pass/fail outputs are not a substitute for engineering reasoning. The report should state what was modelled, what was not modelled, which inputs drive the margin and whether the conclusion changes under credible variations.
Assumptions should be collected in a visible register rather than scattered across calculation sheets. Each assumption should include its source, rationale, direction of conservatism, decision impact, owner and closure trigger. A conservative-looking input is not automatically technically valid.
For detailed API 579 assessment-level education, use NWE’s API 579 FFS Levels 1–3 guide. The integrity report should summarize the selected method and decision basis without duplicating the full calculation tutorial.
Decision Statement, Operating Limits and Remaining Life
The decision statement is the most important paragraph in the report. It should identify the equipment and assessed condition, state the supported outcome, define the operating case, list limitations, state the validity period or reassessment condition and identify what would invalidate the conclusion.
A suitable statement is conditional. It may support continued service within defined pressure, temperature, service, cycles, duration or monitoring limits. It may require repair, rerating, additional inspection, restricted operation, replacement planning or a pause because the evidence is insufficient.
Remaining life should be reported only where the selected method and evidence support a mechanism-specific projection. The report should state the degradation mechanism, data period, future operating assumptions, uncertainty, projected horizon and the inspection or reassessment action that accompanies the number. A standalone remaining-life value can be operationally misleading.
| Report claim | Evidence that must support it | Assumptions / limits | Required owner action |
| Suitable for defined continued service | Verified identity, condition evidence, assessment basis and future operating case | Pressure, temperature, service, cycles, uninspected areas and validity | Operate within limits; monitor triggers; schedule reassessment |
| Repair required | Finding location/extent, engineering basis and repair objective | Temporary controls, access and repair-code/project basis | Define repair scope, owner, due date and post-repair evidence |
| Rerating required | Verified design/condition inputs and revised operating basis | New limits and affected safeguards or relief systems | Approve change, update documentation and operating controls |
| Additional inspection required | Specific uncertainty and its decision impact | Target area, method capability and required data format | Issue targeted scope and capture traceable results |
| Insufficient basis for decision | Missing or contradictory data or unresolved mechanism | No hidden default or assumption | Close the gap, restrict the affected decision or pause scope |
| Replace / retire | Unacceptable margin, recurring degradation, impractical repair or unresolved high-consequence uncertainty | Commercial and operational choice separated from technical minimum | Plan replacement, interim controls and retirement records |
Required Actions, Monitoring and Reassessment
A recommendation is not actionable until the report assigns a priority, responsible owner, due date, required deliverable and closure evidence. Phrases such as “monitor closely,” “repair as required” or “inspect later” leave the operational decision incomplete.
Actions should be separated into immediate controls, short-term evidence or engineering work, planned maintenance or repair and longer-term reassessment. Where an action depends on another discipline, the interface and decision owner should be explicit.
| Action | Priority | Owner | Due / trigger | Closure evidence |
| Confirm operating limit in control-system and operating procedure | Immediate | Operations / Technical Authority | Before return to defined service | Approved procedure and set-point verification |
| Complete targeted inspection of unresolved area | High | Inspection Manager | Before stated decision date or trigger | Traceable report and raw data reviewed by assessment team |
| Develop repair or rerating package | High / planned | Engineering / Maintenance | By agreed outage or risk deadline | Approved engineering package and implementation record |
| Update monitoring and reassessment plan | Planned | Integrity Manager | At report acceptance | Inspection plan, trigger list and responsible owner |
| Close document or identity gap | Planned / blocking | Document Control / Engineering | Before affected calculation or approval | Verified record mapping and revised evidence register |
Reassessment should use both time-based and event-based triggers where appropriate. A date alone may be insufficient if service, temperature, pressure, chemistry, cycles, inspection findings, repair status or configuration changes before that date. The report should state who monitors the trigger and who owns the update.
Approvals, Revisions and Supporting Appendices
The report must make the authoritative revision easy to identify. Show the report number, revision, status, issue date, author, technical checker, approver and owner acceptance role. The exact approval chain depends on jurisdiction and owner procedure; the article does not prescribe a universal signature block.
Revision history should explain what changed and whether the decision or operating controls changed. Superseded copies should not remain in operational use. Appendices should be registered and linked to the decision logic rather than added as an unstructured archive.
Typical appendices may include the evidence register, inspection reports and raw data, drawings, material records, calculation packages, photographs, maps, action register and relevant approvals. Their presence does not prove report quality; the main report must show how each appendix supports the conclusion.
Owner Acceptance Gate
A technically detailed report may still fail the owner acceptance test. The following eight questions provide a quick review before the decision is released to operations, maintenance or management. They are an editorial governance tool, not a regulatory checklist.
| Gate question | PASS evidence | Red flag |
| Can the decision be stated in one paragraph? | Clear outcome, equipment, scope, limits and validity | Only calculations or generic recommendations |
| Can every critical input be traced? | Source register with date, revision, owner and confidence | Copied values with no provenance |
| Is inspection coverage visible? | Maps, locations, extent and limitations | “Inspected” with no boundary |
| Are assumptions and uncertainties decision-linked? | Sensitivity or impact and closure action | Assumptions buried in calculations |
| Are limits operationally usable? | Defined pressure, temperature, service, cycles or triggers | “Operate safely” without conditions |
| Are actions executable? | Owner, priority, due date and closure evidence | “Monitor” or “repair as required” |
| Is reassessment controlled? | Date or event trigger and update owner | No next review or invalidation trigger |
| Is the approved revision identifiable? | Roles, revision log and appendices register | Draft or superseded version in circulation |
A red flag does not automatically mean the engineering analysis is wrong. It means the decision package is incomplete for owner use. The gap should be clarified before the report becomes the basis for operating instructions, maintenance work or capital planning.
Owner acceptance should include the people who must implement the decision, not only the report author and checker. Operations should confirm that limits and triggers are usable; maintenance should understand the work scope and closure evidence; document control should know which revision is authoritative; and the Technical Authority should confirm that unresolved uncertainty is visible. This multidisciplinary review reduces the risk that a technically sound conclusion fails during implementation.
If a conclusion cannot be traced to evidence, assumptions, limits and an owner action, clarify the assessment and reporting scope before accepting the report.
Define the Assessment and Report Scope With NWE
A useful first technical discussion starts with the equipment identity, current finding or concern, available records, decision required and the future operating case. These inputs help define whether the immediate scope is targeted inspection, data-gap closure, FFS engineering or a combined integrity assessment and reporting package.
The requested deliverable should state who needs to use the report and which decisions it must support. Operations may need operating limits and triggers; maintenance needs executable work scopes; the Technical Authority needs evidence and assumptions; management needs decision options and unresolved risk.
To define the assessment and report deliverables, use NWE’s Fitness-for-Service service page. Where condition evidence is incomplete, the scope may also include targeted In-Service Inspection.
Frequently Asked Questions
What is a pressure equipment integrity report?
A controlled technical report that links equipment identity, evidence, engineering assessment, decision, operating limits, actions and approvals for a defined scope.
Is an integrity report the same as an NDT report?
No. An NDT report records the examination and findings. The integrity report interprets relevant evidence within a broader decision basis and connects the conclusion to owner actions.
What should the decision statement say?
It should state the supported outcome, equipment and scope, operating conditions, limitations, validity period and the changes or events that trigger reassessment.
Should a remaining-life number always be included?
No. Include it only when the selected assessment and evidence support a mechanism-specific projection. State the operating conditions, assumptions, uncertainty and validity limits.
How should uncertainty appear in the report?
Identify the source, decision impact, sensitivity or bounding treatment, residual limitation and closure action.
What makes a recommendation actionable?
A clear action, priority, responsible owner, due date, required evidence for closure and escalation rule.
Who should approve the report?
The exact roles depend on jurisdiction and owner procedures, but the author, technical checker, approver and owner acceptance responsibility should be unambiguous.
What are common red flags in integrity reports?
Ambiguous equipment identity, hidden exclusions, untraceable inputs, missing coverage limits, unsupported remaining-life numbers, vague recommendations and no reassessment trigger.
Can one template fit every pressure-equipment assessment?
No. A core architecture can be reused, but exact sections and approvals depend on the equipment, damage, method, code, jurisdiction and owner requirements.
