Guide 11 min read

PSSR evidence before plant startup

Build PSSR evidence for design conformance, procedures, training, open actions, startup boundaries, and accountable approval.

By WizeeMind Team Published on July 2, 2026 Updated on July 2, 2026

Operations and engineering team reviewing PSSR evidence before introducing chemicals to a process unit

A plant can be mechanically complete and still not be ready to start.

The piping may be installed. The punch list may look manageable. The control room may have the new screens. The project team may be tired enough to call the remaining work administrative. Startup is where that confidence becomes dangerous. The question is no longer whether equipment exists. It is whether the plant can be operated, maintained, isolated, monitored, and stopped under the conditions that will exist when energy, feed, pressure, temperature, and people return.

OSHA’s PSM rule requires a pre-startup safety review for new facilities and modified facilities when the modification is significant enough to require a change in process safety information, before highly hazardous chemicals are introduced, with confirmation of design conformance, adequate procedures, resolved recommendations or MOC requirements, and completed operator training (OSHA 29 CFR 1910.119). CCPS defines PSSR as a systematic and thorough check before introducing a highly hazardous chemical to a process (AIChE CCPS PSSR glossary). WizeeMind should assemble that evidence. It should not approve the startup.

Start with the startup boundary

The first weak point in many PSSR records is scope. A project says “mechanical completion achieved,” but the startup boundary is not the same thing as the construction boundary. Startup readiness depends on what will be energized, pressured, heated, cooled, filled, connected, bypassed, staffed, or handed over. If the boundary is vague, the review becomes a polite tour of installed equipment instead of a test of readiness.

OSHA’s PSSR requirement anchors the boundary to the introduction of highly hazardous chemicals and to modifications significant enough to require a change in process safety information (OSHA 29 CFR 1910.119). Marsh’s PSSR position paper widens the practical lens: PSSR can be useful before commissioning or restart for capital projects, modified equipment, new valves or valve operation, new or modified control systems, startup after turnaround, and restart after complex emergency shutdowns (Marsh PSSR position paper). That list matters because a plant can have no dramatic new vessel and still have a new startup risk.

The packet should begin with the exact system, operating phase, and handover state. Which unit, train, line, skid, utility, control-room screen, interlock, permit boundary, and procedure set are inside the review? Which adjacent systems are only interfaces? Which chemicals, utilities, or energy sources will be introduced first? A nitrogen purge, steam-in, electrical energization, solvent charge, catalyst load, or first hydrocarbon feed each creates a different evidence trail.

That is why the boundary should be written in operational language, not project language. “Area A complete” is too soft. “Solvent feed to condenser outlet, including flare interface and control-room restart display” gives operations, maintenance, safety, and engineering the same object to challenge. It also lets the reviewer test whether OSHA’s PSSR categories and Marsh’s restart examples have been covered by evidence rather than assumed from a handover milestone (OSHA 29 CFR 1910.119, Marsh PSSR position paper).

WizeeMind should make the boundary visible before it summarizes any readiness claim:

Startup boundary:
Unit 2 solvent recovery, feed section through condenser outlet.

First introduction:
Steam to reboiler, then solvent feed after line-up verification.

Interfaces:
Tank farm feed pump, flare header, nitrogen supply, control-room display, emergency shutdown logic.

Excluded from this PSSR:
Downstream packaging line and non-process warehouse utilities.

That boundary does not decide whether startup is acceptable. It prevents the decision from floating. Once the boundary is explicit, every missing drawing, incomplete test, unresolved action, or untrained role can be attached to a real startup condition.

Design conformance needs traceable proof

Design conformance is not a sentence in the minutes. It is evidence that installed equipment and controls match the approved design basis closely enough for startup. The temptation is to treat this as construction quality alone: pipe installed, valves tagged, instruments loop checked, insulation complete. Those records matter, but the PSSR question is sharper. Can the team show that the plant condition about to start is the condition that hazard reviews, procedures, and operating limits assumed?

OSHA requires PSSR confirmation that construction and equipment are in accordance with design specifications, and the same PSM standard requires process safety information to include process chemistry, safe upper and lower limits, consequences of deviations, P&IDs, relief system design, design codes, and safety systems such as interlocks, alarms, and detection or suppression systems (OSHA 29 CFR 1910.119). OSHA’s PSM overview frames the standard as a management program integrating technologies, procedures, and management practices for highly hazardous chemical processes (OSHA PSM overview). In practice, the PSSR packet should connect those layers instead of checking them separately.

A useful design-conformance packet should include the approved P&ID revision, line list, equipment data sheets, relief design basis, instrument index, cause-and-effect matrix, alarm set points, interlock proof-test records, control-system change record, material certificates where relevant, and deviations accepted through MOC. For modified facilities, the packet should also show how the change affected process safety information and whether the MOC requirements have been met.

Marsh draws a useful boundary: PSSR is not supposed to redo fundamental design analysis, but it should verify that prior reviews considered the issue, recommendations were implemented, and installed conditions match what should be ready for startup (Marsh PSSR position paper). CCPS makes the same operational point by describing PSSR guidance as a protocol and tool for project or turnaround teams, integrated through project phases with a verification check at the traditional PSSR step (CCPS PSSR guidelines).

WizeeMind should preserve that distinction. It can show that PSV-204 has a relief calculation reference, installation record, inspection result, and accepted deviation. It should not conclude that the relief design is adequate if the basis is missing. It can assemble the evidence trail. Approval remains with qualified human roles.

Procedures and training must match the real startup

The most dangerous procedure at startup is often the one that was correct before the project. The old line-up, old alarm response, old sampling step, or old isolation point may remain in a controlled document because everyone assumed the change was obvious. The startup team then faces a familiar instruction that no longer describes the plant.

OSHA’s PSSR rule requires confirmation that safety, operating, maintenance, and emergency procedures are in place and adequate, and that training of each employee involved in operating the process has been completed before startup (OSHA 29 CFR 1910.119). The CCPS glossary repeats those same readiness categories in its PSSR definition, tying procedures, PHA or MOC status, and completed training to the pre-startup check (AIChE CCPS PSSR glossary). This is where WizeeMind should be strict about source status.

The packet should not merely say “procedures updated.” It should identify the controlled procedure number, revision, approval status, effective date, section changed, startup mode covered, abnormal conditions covered, emergency response link, and whether maintenance and operations use the same version. Training evidence should show who needs training, who completed it, when it was completed, how understanding was verified, and which shift or contractor groups are still missing.

This matters for maintenance too. OSHA’s mechanical integrity provisions require written maintenance procedures, training for employees involved in maintaining process equipment, documented inspection and testing, correction of equipment deficiencies, and checks that equipment is installed properly and consistent with design specifications and manufacturer instructions (OSHA 29 CFR 1910.119). A startup after maintenance is not ready if the operations procedure is current but the maintenance acceptance evidence is unclear.

A practical WizeeMind packet can separate procedure readiness from training readiness:

Procedure evidence:
Startup SOP approved, Rev. 6, effective 2026-07-02.
Emergency depressurization procedure linked.
Maintenance acceptance checklist signed for pump P-410B.

Training evidence:
Day shift complete.
Night shift complete except two operators assigned as standby.
Contractor instrument technician briefed on energized-panel boundary.

Gap:
No record that temporary startup sampling frequency was briefed to laboratory staff.

That gap may be small. It may also be the exact gap that delays startup. The tool should not smooth it out.

Open actions are not all equal

A startup packet will almost always contain open actions. Some are housekeeping. Some belong after startup. Some are startup blockers. The hard part is not listing them. The hard part is proving who has the authority to classify them, what risk remains, what temporary controls exist, and when the action must close.

Marsh describes PSSR team sign-off scenarios in three categories: ready to start or move to the next phase, may start with issues assigned for after startup, or may not start until certain issues are dealt with (Marsh PSSR position paper). It also calls for action tracking and says centralized action-tracking systems should be used where organizations have them. CCPS’s PSSR guidelines emphasize checklists, validation, documentation, and integration through project or turnaround phases so surprises do not concentrate at the final review (CCPS PSSR guidelines).

The contrarian point is that a short punch list can be more dangerous than a long one if the short list hides classification. “Instrument checks remaining” is not acceptable evidence. Which instrument? What function? Alarm, permissive, trip, indication, custody transfer, quality measurement, or convenience display? Does startup depend on it? Was a temporary control approved? Who owns it during the first shift?

The BP Texas City refinery explosion is a sober reminder of why startup deserves this discipline. The CSB reports that the March 23, 2005 explosions occurred during restarting of a hydrocarbon isomerization unit, killing 15 workers and injuring 180, after a distillation tower flooded and overpressurized during startup conditions (CSB BP Texas City investigation). The CSB recommendations on that investigation addressed maintained and tested equipment, repair of malfunctioning process equipment before unit startups, additional board operator staffing during startup, knowledgeable supervision during hazardous startup phases, updated startup procedures, and tracking recommendations to completion (CSB BP Texas City investigation).

According to the U.S. Chemical Safety and Hazard Investigation Board, that event shows why startup evidence has to cover equipment condition, procedures, staffing, supervision, training, hazard review, and action closure. It is not enough to say the plant was built.

WizeeMind should classify actions into startup blocker, permitted post-startup action, evidence gap, owner decision needed, and informational item. It should keep the human approver visible beside each classification. A tool can assemble the list. It cannot turn an unresolved safeguard into an acceptable risk.

Keep approval outside the assistant

The cleanest product boundary is also the most important one: WizeeMind should not approve startup. It should assemble evidence, expose gaps, show conflicts, track actions, and route the packet to accountable people. Approval is a human authority boundary because startup accepts residual risk in a real plant.

OSHA’s PSM overview describes PSM as a comprehensive management program that integrates technologies, procedures, and management practices (OSHA PSM overview). That integration is the reason approval cannot be reduced to a document score. OSHA’s PSSR clause requires confirmation across design conformance, procedures, PHA or MOC status, and training before introduction of highly hazardous chemicals (OSHA 29 CFR 1910.119). Those confirmations require judgment about the plant, not only retrieval of records.

The product should also avoid a subtler failure: turning missing evidence into a neutral status. A blank training record, an unsigned display check, or an unresolved PHA recommendation is not “probably fine” because other fields are complete. CCPS frames PSSR as a systematic check before introduction of hazardous material, and Marsh describes explicit sign-off choices that distinguish ready, conditionally ready, and not ready (AIChE CCPS PSSR glossary, Marsh PSSR position paper). WizeeMind should preserve that discomfort.

Marsh is explicit about roles. It recommends assigning a PSSR leader with sufficient process-safety experience, building a multidisciplinary team, and obtaining managerial sign-off that the plant is ready to start or move to the next phase (Marsh PSSR position paper). The same source identifies team participants such as design engineering, operations, maintenance, MOC coordination, instrumentation, process engineering, safety, inspection, and emergency response. The CCPS book page similarly frames PSSR around people responsible for scheduling and executing the review, not automated authorization (CCPS PSSR guidelines).

A WizeeMind approval screen should therefore look restrained:

Evidence assembled:
Design conformance records, procedure revisions, training records, open-action list, startup boundary, and MOC references.

Evidence gaps:
Two temporary controls need role approval.
One night-shift training record missing.
Control-room display verification not signed.

System boundary:
WizeeMind does not approve startup.
PSSR leader and accountable manager must review and sign.

That refusal is not a limitation to hide. It is the control. The assistant can reduce search time across CMMS records, drawings, procedures, training exports, shift logs, MOC packets, and action trackers. It can make weak evidence uncomfortable. It can prevent a tidy summary from covering missing authority. The final startup decision remains where it belongs: with named people who understand the process, the hazards, and the consequences.

Build the packet for the first shift after startup

A PSSR record should not be written only for the sign-off meeting. It should be useful during the first shift after startup, when the plant starts teaching the team what the review missed. The first shift needs to know the boundary, expected operating limits, temporary controls, startup-specific alarms, watch points, open post-startup actions, escalation owners, and stop conditions.

CCPS defines PSSR as a systematic and thorough check before highly hazardous chemicals enter the process (AIChE CCPS PSSR glossary). Marsh notes that a PSSR team may visit the actual installation and the control room, complete checklists, list action items, and track PSSR actions after the review (Marsh PSSR position paper). Those steps should leave behind a packet that operations can use, not just an archive for auditors.

The packet should contain:

startup boundary and first introduction of energy or chemicals,
approved procedures and revision status,
design-conformance evidence and accepted deviations,
completed training by role and shift,
open actions classified by startup impact,
temporary controls, expiry, and owner,
control-room readiness and alarm or interlock checks,
field verification points and sampling requirements,
named PSSR leader, approver, and escalation owner,
conditions that require stopping startup or returning to review.

This is where WizeeMind can help without overstepping. If a board operator asks why a temporary alarm limit exists, the packet can show the MOC reference, approved duration, operating envelope, and responsible engineer. If maintenance asks whether a pump vibration watch is mandatory, the packet can show the post-startup action owner and inspection frequency. If a supervisor asks whether startup can continue after a failed instrument check, the packet can show that the item was classified as a blocker. It should not decide to continue.

The closing action is plain: build the PSSR packet before the startup meeting, not during it. Start with the boundary. Link every readiness statement to a controlled source. Keep open actions classified and owned. Show who has authority. Leave gaps visible. A plant that can do that has not automated startup approval. It has made startup approval harder to fake and easier to defend.