The FEED HAZOP identified the hazards. Detailed engineering is where every action item either gets resolved or becomes a construction problem. SafeGuard Projects tracks that resolution — action register to IFC P&ID.
Discuss Your Project See Full LifecycleFEED produced the HAZOP, the SIL targets, and the PSM compliance roadmap. Detailed engineering is where those outputs get built into the actual design. Miss the window and every unresolved action item becomes a field modification, a schedule slip, or a startup risk.
Most HAZOP action registers are created during FEED and then lose their owner. By the time the IFC P&IDs are issued, nobody can confirm which actions are closed, which are open, and which were intentionally waived. SafeGuard Projects maintains that register through detailed engineering — every action tracked, every resolution documented, every waiver reviewed.
Maintain, track, and close HAZOP and PHA action items through detailed engineering. Every action assigned, documented, and resolved before IFC issue. No unresolved actions carried forward to construction.
Verify SIS detailed design against SIL targets from LOPA. Review logic solver selection, sensor and final element specifications, proof test procedures, and software lifecycle documentation per IEC 61511.
Alarm philosophy application across the detailed design. IPF-by-IPF review against the alarm philosophy. Alarm rationalization per IEC 62682 — priority, deadband, setpoint, and suppression logic.
Independent review of C&E matrices for safety-critical logic. Verify that SIF triggers, de-energized-to-trip logic, and inhibit conditions are correct, complete, and consistent with the HAZOP and LOPA outputs.
PSM-compliant operating procedures developed in parallel with the design — not written in the final weeks before startup. Normal operations, abnormal conditions, emergency shutdowns, and startup/shutdown procedures.
Review of equipment specifications for safety-critical items — PRDs, BDVs, SDVs, fire and gas detectors, deluge systems. Verify that design basis from the PSI package is correctly translated into equipment specs.
A HAZOP without a closed action register is not a HAZOP — it is a list of known hazards that were never fixed. SafeGuard Projects treats the action register as a live document, not a handoff deliverable.
Receive the FEED HAZOP action register. Assign owners, due dates, and resolution criteria. Categorize actions by type — design change, SIS addition, operating procedure, further study.
Weekly or biweekly review of open actions with the engineering team. Document how each action is resolved — P&ID revision number, specification revision, or formal waiver with rationale.
Verify that design changes required by HAZOP actions are correctly reflected in the issued P&IDs. Mark-up review against the action register. Flag discrepancies before IFC issue.
Formal action register close-out report at IFC issue. Every action dispositioned — closed with evidence, formally waived, or carried forward with documented rationale. Input to PSSR checklist.
SIL targets from LOPA mean nothing if the SIS is not designed to achieve them. SafeGuard Projects reviews SIS detailed design packages against IEC 61511 before construction locks in the architecture.
| Review Element | Standard |
|---|---|
| Logic solver selection & SIL capability | IEC 61511 |
| Sensor and final element specifications | IEC 61511 |
| Proof test interval verification | LOPA outputs |
| Software lifecycle documentation | IEC 61511 |
| Bypass and inhibit management | IEC 61511 |
| C&E matrix completeness | HAZOP actions |
| Deenergized-to-trip philosophy | IEC 61511 |
SIS design errors that survive into construction are expensive to correct. Errors that survive into operation are dangerous. IEC 61511 requires that the SIS is designed to achieve the SIL target — and that someone verifies it. That someone is SafeGuard Projects.
Detailed engineering is when the alarm list grows from a P&ID markup into hundreds of configured alarms. Without rationalization, operators inherit an alarm flood — and alarm floods kill people. SafeGuard Projects applies the alarm philosophy to every alarm in the system.
Emergency / High / Low priority per alarm philosophy. Response time and consequence documented for each.
Alarm setpoints based on operating limits, not arbitrary percentages. Process safety case documented for each safety alarm.
Chattering alarms identified and deadband/time delay specified before commissioning. Not discovered during startup.
Alarm suppression logic documented and reviewed. Inhibited alarms require management authorization — not routine console action.
29 CFR 1910.119(f) requires written operating procedures that address each operating phase — startup, normal operations, temporary operations, emergency operations, and shutdown. The statute doesn't require that they be written three weeks before the PSSR. That is what happens without SafeGuard Projects.
Operating procedure framework established during detailed engineering — unit operations identified, procedure boundaries set, operating limits compiled from PSI.
Draft procedures written against the detailed design — referencing instrument tag numbers, equipment numbers, and set points from the design documents.
Draft procedures reviewed by operations team. Gaps between design intent and operational reality captured and fed back to engineering for resolution.
Procedures updated to align with IFC P&IDs before construction. Ready for commissioning training — not written from scratch during the PSSR.
Don't let HAZOP actions close without documentation. Let's review your action register and build a resolution plan before IFC.
Start the Conversation Construction Phase →