The most dangerous change request in a plant rarely looks dangerous at first glance. It looks reasonable. A pump runs on an alternate lineup while the preferred unit is repaired. A supplier substitution lands because the original spare is delayed. A procedure gains one extra cleaning step. A contractor absorbs a routine inspection. The shift pattern changes, and the same job now happens with thinner supervision at 03:00.
None of those moves automatically creates a serious process safety risk. The trap is more ordinary: the team approves from memory, then tries to reconstruct the evidence later.
Management of change should stop that drift. OSHA’s PSM rule requires written procedures for changes to process chemicals, technology, equipment, procedures, and facilities that affect covered processes, except replacement in kind (OSHA 29 CFR 1910.119). CCPS describes MOC as a review and authorization process that checks whether a proposed adjustment could introduce new hazards or increase existing risk (AIChE CCPS introduction to MOC). WizeeMind’s useful role is not approval. It is evidence assembly: the packet that lets qualified people see what is known, what is missing, and what must be decided.
Start the packet before the change earns attention
The weak MOC usually starts with a classification error. Everyone recognizes the large project: new vessel, new control strategy, building change, major equipment replacement. Smaller moves get handled as “just maintenance” or “just operations” until someone asks which procedure, limit, alarm, training record, drawing, permit, or staffing assumption changed.
OSHA’s MOC language is a good first screen because it names the evidence categories that must be addressed before a covered change: technical basis, safety and health impact, modifications to operating procedures, necessary time period, and authorization requirements (OSHA 29 CFR 1910.119). CCPS adds a practical operating view: MOC should cover adjustments to facility design, operations, organization, or activities before implementation, and it should keep affected personnel informed and documents current (AIChE CCPS introduction to MOC).
A useful WizeeMind packet should therefore begin with the change object, not the approval form. What exactly moved? A setpoint, spare part specification, cleaning method, inspection frequency, bypass condition, alarm response, contractor task, staffing model, or document revision each points to different evidence.
The first page can be plain:
| Change question | Evidence WizeeMind should assemble |
|---|---|
| What is changing? | asset, process, procedure, role, material, software, facility, or temporary condition |
| Why now? | failure record, production constraint, supplier issue, safety action, quality deviation, or project scope |
| What might be affected? | hazards, controls, procedures, permits, training, drawings, PSI, maintenance, quality, and contractor work |
| Who must decide? | operations, engineering, maintenance, safety, quality, training, contractor owner, and accountable leadership |
That table does not prove the change is acceptable. It prevents the opening review from becoming a confident conversation with missing records. The packet should make thin evidence visible early, when the team can still slow down.
One practical rule helps: if the proposed work changes how a person will operate, maintain, inspect, isolate, clean, start, stop, or document the process, put it through the MOC screen before arguing about size. The screen can still conclude that the change is simple. It should not conclude that from a title alone.
Treat temporary change as a controlled state, not a favor
Temporary changes are where process discipline gets negotiated away with the best intentions. Production needs to continue. Maintenance needs time. The workaround is written down somewhere. The plant survives the first day. Then the temporary condition becomes familiar, and familiarity starts impersonating approval.
The law is deliberately specific here. OSHA includes the “necessary time period for the change” among the considerations that must be addressed before a covered change is made (OSHA 29 CFR 1910.119). IChemE’s Safety Centre guidance takes the lifecycle further: capture and close-out should verify that documentation, systems, processes, communication, and training have been updated, and temporary changes should be removed with documentation returned to the original state where appropriate (IChemE Safety Centre MOC guidance).
The contrarian point is that a temporary change often needs a stronger evidence trail than a permanent one. A permanent change usually attracts project controls. A temporary change lives inside daily pressure. It crosses shifts, handovers, work orders, permits, and informal memory. That is where a clock matters.
A temporary-change packet should state the approved start, expiry, extension rule, operating limits, added checks, affected procedures, training or notification record, and closure evidence. For example, an alternate pump lineup should not be described only as “P-204A unavailable.” The packet should show the repair work order, affected flow limits, extra bearing-temperature check, alarm response differences, shift handover note, supervisor confirmation before startup, and the date when the arrangement expires.
WizeeMind can help by keeping the temporary state visible. It can pull the active work order, current shift note, latest inspection record, and procedures that still describe the normal lineup. It can flag that the expiry date has passed or that night shift has no training acknowledgement. It should not silently convert an expired workaround into the new normal. That decision belongs to the people accountable for the plant condition.
Organizational change belongs in MOC when hazard controls depend on people
Plants often treat organizational change as an HR event until the work reaches the control room, workshop, permit office, or contractor boundary. By then the evidence is late. A new shift pattern changes who supervises startup. A contractor takes over an inspection. Maintenance budget pressure stretches test frequency. A senior operator retires, and a procedure suddenly depends on knowledge that was never written down.
OSHA’s 2009 memorandum on management of organizational change is direct about this boundary. Richard E. Fairfax, then Director of OSHA’s Directorate of Enforcement Programs, explained that organizational, personnel, and policy changes can trigger MOC when they affect process chemicals, technology, equipment, procedures, or facilities in a PSM covered process (OSHA organizational change memorandum). The memo gives examples including staffing levels, staff experience, contracting out, and budget cuts that affect PSM covered processes.
HSE reaches the same practical concern from a human factors angle. Its organisational change guidance says staffing reductions, contractors, outsourcing, combined departments, and changed responsibilities are often not analyzed as thoroughly as plant or process changes, even though subtle organizational changes can affect hazard management (HSE organisational change). It also warns against too many simultaneous changes and calls for assessment of direct and indirect effects on hazard control.
The packet should make those dependencies explicit. Which tasks move between roles? Which permits, inspections, emergency duties, isolations, handovers, or abnormal-condition responses depend on the affected people? Which competence evidence exists? Which contractor scope boundaries changed? Which open actions transfer from the prior owner?
This does not mean every schedule tweak deserves a large formal review. The test is narrower and more useful: does the people change alter how process hazards are controlled? If yes, the evidence belongs beside the technical change record. WizeeMind should not label a staffing decision safe. It should show the work that could be weakened, overloaded, transferred, or left ownerless.
Keep facts, gaps, and approvals in separate lanes
A generated summary can make a weak change request look tidy. That is the wrong kind of help.
The MOC packet should separate four lanes: facts already supported by plant records, proposed decisions, open gaps, and approvals required from accountable roles. OSHA requires authorization requirements to be addressed before a covered change, and it requires affected operating, maintenance, and contract employees to be informed of and trained in the change before startup of the affected process or part of the process (OSHA 29 CFR 1910.119). CCPS similarly describes a documented, reviewed, and authorized change request with risk controls, document updates, and communication or training outputs (AIChE CCPS introduction to MOC).
Those requirements map neatly to a packet structure:
- known facts supported by records,
- assumptions that need human confirmation,
- documents and records affected,
- risk controls proposed or already in place,
- training and notification evidence,
- authorization roles,
- closure evidence.
The structure matters because plant decisions span functions. Operations may know the running condition. Engineering may own the technical basis. Maintenance may know whether the asset can be supported. Safety may evaluate hazard controls. Quality may own product impact. Training may need to confirm affected people understand the change. A clean packet keeps those lanes visible instead of blending them into one polished paragraph.
This is also where source labels matter. A historian trend can support a claim about operating behavior. A work order can support a claim about repair history. A controlled procedure can support a claim about the approved method. A shift note can support a claim about what was communicated during a handover. None of those records can replace the others. When WizeeMind labels each fact with its source, the reviewer can see whether the packet rests on hard records, informal notes, or an assumption waiting for confirmation.
Here is the tone WizeeMind should prefer:
Known:
Alternate valve lineup proposed for temporary cleaning sequence.
Procedure section identified.
Maintenance confirms current valve tags.
Missing:
No documented technical basis for changed flow path.
No confirmation of alarm or interlock impact.
No training record for night shift.
No expiry date for temporary use.
Boundary:
Evidence can be assembled.
Approval cannot be supported until accountable roles review the gaps.That is useful precisely because it refuses to overstate the evidence. A reviewer can challenge the gaps. A weaker system would write, “The change has been evaluated,” and leave everyone to discover later what that sentence did not mean.
Approval, startup, extension, and close-out are different decisions
MOC fails when the team treats it as one yes-or-no moment. The plant actually makes several decisions. Should the change be approved? Is the affected system ready for startup? Can a temporary change be extended? Can the record be closed? Each question needs different evidence.
OSHA separates pre-change review, training before startup, updates to process safety information, and updates to operating procedures or practices when the covered change affects them (OSHA 29 CFR 1910.119). IChemE’s guidance makes the sequence even clearer: review, approve, implement, capture, and close-out, with pre-startup safety review, training, communication, updated drawings, updated procedures, maintenance-system updates, and closure of risk-assessment actions (IChemE Safety Centre MOC guidance).
That distinction changes the packet design. Approval evidence asks whether the proposed change has a technical basis, hazard review, controls, scope, and authorizers. Startup evidence asks whether the plant is ready to run with the change: training complete, documents available, actions closed or intentionally deferred, and affected people informed. Extension evidence asks whether the original assumptions still hold. Close-out evidence asks whether the plant condition, drawings, procedures, training, maintenance plans, and records caught up with reality.
Temporary-change extension deserves special scrutiny. The risk may increase even when nothing obvious breaks. Shift teams rotate. Contractor coverage changes. A maintenance backlog grows. A procedure update waits for document control. HSE’s guidance to avoid too many simultaneous organizational changes fits this problem well because multiple small changes can overload hazard controls (HSE organisational change).
WizeeMind should show these decision gates separately. One visible status for approval. Another for startup readiness. Another for temporary expiry or extension. Another for closure. The system should make it uncomfortable to close a record while the procedure still references the old lineup, the drawing remains unissued, or the maintenance strategy has not been updated.
That separation also protects good decisions from lazy close-out. A change may be correctly approved and still not be ready for startup. A temporary change may be acceptable for seven days and unacceptable for a second extension. A completed installation may still need training evidence before the MOC record closes.
Design WizeeMind around evidence boundaries
The best plant assistant for MOC is not the one that sounds most decisive. It is the one that knows when a decision is outside its authority.
Hydrogen Tools describes MOC as a process for reviewing proposed changes to materials, technology, equipment, procedures, personnel, and facility operations before implementation to determine effects on safety vulnerabilities (Hydrogen Tools MOC guidance). CCPS also emphasizes qualified review, authorization, affected-personnel notification, and document updates rather than automatic approval (AIChE CCPS introduction to MOC). Those sources point toward a practical product boundary for WizeeMind.
WizeeMind should assemble, compare, and expose evidence. It should not decide that a change is replacement in kind, waive training, authorize startup, extend a temporary change, approve risk acceptance, or close a record with missing documentation. Those are governance decisions.
The tool should help teams answer concrete questions:
- Which records support the technical basis?
- Which procedures, drawings, PSI records, permits, training materials, and maintenance plans may be affected?
- Which employees, contractors, shifts, and neighboring functions need communication or training?
- Which assumptions are unsupported?
- Which temporary changes are approaching expiry?
- Which close-out actions remain open after implementation?
That is enough value. It reduces the time spent searching across CMMS notes, procedures, shift logs, drawings, training exports, and risk assessments. It also reduces the pressure to make a review sound complete before it is complete.
The interface should reward restraint. Empty evidence fields should remain empty, not be filled with generic prose. Conflicting records should stay visible side by side. If the procedure says one valve lineup and the shift log describes another, the packet should show the conflict and route it to the accountable reviewer. Neat wording is less useful than traceable uncertainty.
The final packet should be reviewable by another qualified person months later. What changed? Why was it proposed? Which hazards and controls were considered? Who was affected? Which documents moved? What evidence supported approval, startup, extension, and close-out? A plant that can answer those questions has not automated responsibility. It has made responsibility easier to exercise.