A source drawing changes after a safety assessment has been prepared. The next reviewer needs to know which decisions relied on the earlier revision, and which records need attention.

The same question arises when a team moves from a Hazard and Operability study (HAZOP) to a Layer of Protection Analysis (LOPA). The connection needs to preserve the engineering basis: the selected scenario, source revisions and decisions made at the handover.

This is a software-design problem as well as an engineering task. A connected application preserves those relationships while giving the next reviewer room to make a separate assessment.

Keep the scenario identifiable.

CCPS describes a LOPA scenario in terms of a single cause–consequence pair and sets criteria for evaluating independent protection layers. A broad HAZOP worksheet can contain several related records; the application needs to make the selected source unambiguous.

Store a stable reference to the source cause and consequence, alongside their study and node context. Keep the wording used when the linked assessment was created. A reviewer can then compare the current source with that earlier basis instead of guessing whether two similar descriptions refer to the same scenario.

The source reference and the saved wording serve different purposes. One finds the live engineering record. The other explains what the assessment actually relied on at the time.

Reference: CCPS — LOPA overview and independent protection layers

Make the handover inspectable.

Before choosing a worksheet layout, define the information that must survive the handover. The following is a proposed software record checklist. The engineering team determines the required assessment method and acceptance criteria.

The HAZOP-to-LOPA handover
  1. 01Source scenario

    Cause, consequence and the engineering context.

  2. 02Assessment basis

    Selected scenario, candidate layers and supporting information.

  3. 03Review history

    The decision, its status and the changes that follow.

Figure 1. The source scenario, assessment basis and review history remain connected while the assessment retains its own engineering decisions. A proposed software record structure.

Scroll horizontally to read all columns.

HAZOP-to-LOPA record checklist
RecordWhat the software should retainWhat remains a review decision
Source scenarioStudy, node, cause and consequence references; wording at handover.Whether the selected scenario is suitable and correctly bounded.
Engineering contextRelevant drawing or document identifiers and revisions.Whether the context is sufficient and approved for this assessment.
Candidate safeguardsThe source description and its engineering reference.Whether each candidate qualifies for credit under the adopted method.
Assessment basisInitiating-event basis, credited layers, assumptions and supporting references.The appropriateness of the inputs, independence and assessment conclusions.
Review historyReviewer, date, status and reasons for material changes.Who accepts the assessment and what requires further work.

Separate a safeguard from a credited layer.

A safeguard named in the HAZOP should remain visible when preparing the LOPA. Its presence in that list is not enough to treat it as a credited independent protection layer. CCPS identifies independence and other attributes that need assessment.

The interface should distinguish a candidate safeguard, a reviewed layer and an unresolved question. Give each candidate a place for its assessment basis, supporting evidence and reviewer decision. Avoid a workflow in which importing a row silently assigns credit.

This distinction also helps when an engineer rejects a proposed layer. The original safeguard remains part of the source study; the linked assessment retains the reason it was not credited.

Reference: CCPS — LOPA overview and independent protection layers

Make changes visible without rewriting history.

Suppose the consequence wording or a referenced drawing changes after a LOPA is reviewed. The software should expose the relationship and the difference, while retaining the basis of the reviewed assessment. An automatic overwrite would remove information needed to understand the earlier decision.

A practical design records the source version, identifies affected linked assessments and lets the responsible reviewer decide whether revision is required. The same principle applies when an assessment informs later safety-function work: a link should carry context, not imply that downstream work is automatically approved.

VISCOS follows this connected-study direction across HAZOP, LOPA and safety-function design. When reviewing an engineering platform, ask it to demonstrate a changed source record and the resulting review path. The demonstration should make the source revision, affected assessment and review decision visible.

  • Can the reviewer open the exact source scenario?
  • Can they distinguish current source information from the assessment basis?
  • Are candidate safeguards and credited layers visibly different?
  • Can a material change be traced through the related work?

Reference: VISCOS — connected process-safety engineering

Sources & further reading

CCPS provides the assessment definitions referenced here. The record checklist and proposed change-review behavior are Gray Foundry software-design recommendations.