Asset integrity software: connect anomalies to work orders without merging their authority

Topics: asset integrity management software, oil and gas maintenance software, maintenance management software.

An inspection finding is entered in the integrity register and corrective work is raised in the maintenance system. Weeks later the work order says complete, but the register still lacks the evidence needed for the integrity engineer's disposition. Another anomaly has an approved action but no acknowledged work order. A dashboard that merges both into “maintenance complete” conceals the two different gaps.

Design the interface around a traceable handoff and a separate engineering review of returned evidence. Asset Integrity Management (AIM) records the finding and authorised technical decision. The Computerised Maintenance Management System (CMMS) records planning and execution under the site's work-control arrangements. Connect their identities and evidence without treating one system's status as the other's technical approval.

Draw the boundary before mapping statuses

Wall-thinning observations, corrosion under insulation (CUI) findings and records concerning temporary repairs can require different qualified decisions. This guide does not grade those conditions, determine repair suitability or calculate remaining life. It concerns the interface record supporting the people who hold that authority.

API's inspection-training material treats Fitness-for-Service (FFS), associated with API 579-1/ASME FFS-1, as a technical assessment discipline. It is not a property created by completing a software task. The applicable standard edition, engineering evaluation and asset decision require qualified review; no assessment method, inspection interval or operating limit is supplied here. API inspection training.

Use a field-level ownership agreement:

IBM's published work-order-status reference distinguishes completed work from closed work. Even such native maintenance distinctions must be mapped explicitly; neither label by itself supplies an engineering anomaly disposition. Installed status synonyms and automation still need verification. IBM Maximo work-order statuses.

1. Step 1 — Record intake & baseline identification: The integrity register owns the approved anomaly decision; the CMMS owns the maintenance execution record. A completed work order must not automatically close the anomaly.
2. Step 2 — Cross-system reference & custody linkage: Preserve stable asset, anomaly, engineering-decision and work-order references, including one-to-many relationships and later revisions.
3. Step 3 — Exception quarantine & authority check: Keep engineering priorities, operating restrictions and next-review dates under their authorised owners. The interface transports approved values and exposes conflicts.
4. Step 4 — Verified disposition & audit trail closure: Pilot one asset class in a sandbox with duplicate, partial, late and cancelled-work cases before considering production writes.

Make the handoff reconstructable in both directions

Send the asset/location identity, anomaly ID and revision, approved decision reference, requested work scope reference, evidence links and mapping version. The receiving system returns its work-order ID and acknowledgement. A successful message send is not evidence that a valid order exists.

Allow the approved relationship model to express one anomaly requiring several work orders and one work package addressing several anomalies. Do not force a one-to-one relationship simply because it is easier to display. Each anomaly still needs its own evidence and disposition scope. If a shared work order completes only one task, that must not close every linked anomaly.

Return execution evidence with task and asset references, completion time, relevant inspection/test-document references and outstanding items. Maintenance owns the accuracy of its execution record. The integrity reviewer decides whether that evidence satisfies the approved action, whether more information is needed, and whether the anomaly can close or remain under an approved disposition. Administrative closure never substitutes for the site's authority to operate or return equipment to service.

• Primary control scope: asset integrity management software across maintenance and connected ERP/EAM records.
• Segregation boundary: Operational status updates never auto-close engineering, safety, or finance sign-off gates.
• Verification cadence: Reconcile open exceptions, overrides, and late adjustments at each shift or period close.

Worked example: handoff coverage and closure evidence use different denominators

The following is an illustrative synthetic administrative fixture. No real anomaly, asset assessment, engineer approval or operating decision is represented. Counts describe records in one agreed test snapshot, not defect severity or acceptable backlog.

There are 12 anomaly records. For this fixture, 10 have an authorised action requesting corrective-work handoff; two have separately recorded monitoring decisions and do not currently request a work order. Of the 10 work requests, eight have acknowledged CMMS order references and two remain unresolved interface cases.

Acknowledged handoff coverage is 8 ÷ 10 × 100 = 80%. Dividing eight by all 12 would give 66.7%, but would mix the two monitoring records into the work-request denominator. The two monitoring records still need their authorised review dates and owners; excluding them from this metric does not mean ignoring them.

Assume the eight acknowledged orders are one-to-one with their anomalies in this fixture. Five orders report execution complete. Only three of those five have received the fixture's explicit final integrity dispositions; two await evidence review. Evidence-review completion among execution-complete cases is 3 ÷ 5 × 100 = 60%.

Only three anomalies are recorded closed in this fixture; nine remain open under different states. Neither 80% nor 60% establishes asset integrity performance or acceptable risk. The useful result is a list of identifiable records requiring the correct owner next.

Preserve meaning when the systems disagree

An asset tag maps to two assets. Quarantine the handoff for identity resolution. Do not choose the first search result or copy the work order to both assets.

A create-order request times out. Treat the outcome as unknown and query using the source handoff reference before retrying. Duplicate delivery should produce one acknowledged relationship, not a second order. Retain receipt and application states separately.

An engineering decision changes after planning. Send a new version and flag affected orders for owner review. The CMMS must acknowledge the revised scope or record why it has not applied it. A late older message cannot overwrite the new decision or extend a review date.

The work order is cancelled or partly completed. Return the actual state and affected tasks. The integrity owner reviews whether another action is required; cancellation is not anomaly closure. Partial evidence remains partial.

A temporary-repair record is mentioned. Link its authorised engineering decision and monitoring obligations without treating the word “temporary” as a calculated expiry. The integration must not invent clamp suitability, review intervals or operating permissions.

The integration is unavailable. Make the interface outage visible and follow the approved manual record handoff. Preserve source references on manual orders. Reconcile them before replaying the queue, with conflicts routed to the relevant owners. Stop writes on ambiguous asset identity, lost approval provenance or unreconciled state; restore only after the interface owner and accountable record owners accept recovery.

A bounded pilot for one anomaly-to-work flow

Use one asset class and one site boundary, with synthetic or expressly authorised minimised records. Start with read-only extracts or sandbox endpoints. Inputs are the asset cross-reference, anomaly revisions, approved action references, work-order/task status definitions and evidence links. There is no connection to equipment controls, no new technical grading and no return-to-service action in this pilot.

Establish the current baseline on an agreed snapshot/window: work-request records lacking acknowledged orders, orders linked to the wrong/unknown asset, execution-complete cases awaiting integrity review, and time spent reconciling those records. Record sample size and unknowns; no reduction is assumed.

Compare three options against the same fixture: a controlled manual cross-reference, configured AIM/CMMS relationship fields, and an integration with acknowledgements and an exception queue. Build a separate application only if those leave a specific unresolved workflow. Deterministic identity/version/status rules fit this work. AI may summarise cited evidence for a reviewer, but cannot set grading, restrictions, due dates or closure.

The pilot exits only after owners can retrieve every fixture's source decision, acknowledged order relationship and returned evidence. It must reproduce the 80% handoff and 60% review calculations, retain the nine open states correctly, prevent duplicate creation, reject stale updates and survive a simulated outage with reconciled manual records. A shared-order fixture should also show that one completed task cannot close unrelated anomalies. These are proposed acceptance tests, not passed results.

If a critical identity or authority check fails, keep the interface read-only and correct the affected mapping. A sponsor's decision to expand integration scope must follow the integrity, maintenance and system owners' acceptance of the record controls.

Keep the next engineering decision visible

The AIM–CMMS boundary works when a reviewer can follow the finding, approved action, executed work and final disposition without interpreting a generic green status. That makes missing work acknowledgements and missing engineering evidence visible as different problems with different owners.

1. Map one asset class's anomaly, decision and work-order identities with integrity and maintenance owners.
2. Agree which system owns each field and which status changes require an explicit engineering disposition.
3. Baseline missing acknowledgements and pending evidence reviews using separate denominators.
4. Rehearse changed decisions, shared orders, cancellations and outage replay in a sandbox before approving write scope.

Frequently Asked Questions

How should oil and gas operators structure the software interface between Asset Integrity Management (AIM) anomaly registers (wall-thinning, CUI, temporary repair clamps) and CMMS corrective work-order execution?

Teams should govern asset integrity management software by linking every transaction to its source evidence, timestamp, and assigned owner before permitting downstream posting. Distinct from O038 (inspection-evidence-register, which tracks NDT inspection document packs) and O042 (cmms-erp-transaction-ownership); O101 defines the software boundary between AIM engineering anomaly grading/next-inspection due dates and CMMS execution orders, ensuring software records do not substitute for Fitness-for-Service (FFS) engineering evaluations. Rather than relying on informal spreadsheet overrides, the workflow enforces a documented verification gate and preserves the original observation whenever a correction is recorded.

How does oil and gas maintenance software handle exceptions and mismatches?

When a discrepancy occurs during oil and gas maintenance software, the system routes the blocked record into an owned exception queue rather than silently dropping or auto-adjusting the balance. Record anomaly-to-CMMS handoff and traceability only. Qualified integrityengineer owns fitness-for-service, repairpriority, operating limits and returntoservice; no autonomous engineeringdisposition. Each exception retains the original quantity, date, and counterparty reference until the designated reviewer resolves the variance with supporting evidence.

What should teams test before automating maintenance management software?

Before scaling maintenance management software, run a bounded pilot using historical records that include partial receipts, late updates, duplicate messages, and rejected lines. Verify that the integration preserves idempotency, maintains a clear segregation of duties between operational entry and financial approval, and produces an auditable trail for every state transition.

Summary and next actions

1. Map the current asset integrity management software record boundaries, system of record, and named approval owners before changing workflow rules.
2. Separate operational status updates from engineering, safety, or financial disposition sign-off.
3. Validate exception queues, duplicate handling, and cutoff reconciliation in a bounded pilot before production rollout.