The MOC That Writes Itself

Management of Change is, on paper, a straightforward concept: before you modify equipment, a procedure, or an organizational structure in a way that could affect process safety, you document the change, assess the hazards, obtain the right approvals, and close out the record once the work is complete. The regulatory framework that mandates this — OSHA PSM under 29 CFR 1910.119 for onshore operations, SEMS under 30 CFR 250 Subpart S for offshore — is explicit about what must be addressed in the change package.

In practice, MOC is one of the most time-intensive workflows in process safety. A typical MOC package for a non-trivial modification — replacing a control valve, changing a chemical injection rate, modifying an operating procedure — requires somewhere between 8 and 40 hours of engineering time to produce. On a facility running 30 to 60 MOCs per year, that is a significant fraction of the engineering team's available capacity. The documentation is largely templated, the information largely retrievable from existing records, and the review process largely sequential. These are the conditions under which AI-assisted automation produces measurable results.

This is not a vision piece. Here is what an AI-assisted MOC process actually looks like.

What the Package Actually Contains

A complete MOC package under PSM or SEMS covers several distinct document categories. The change description must specify what is being modified, the technical basis for the change, and the expected duration. The hazard review — typically a HAZOP checklist or a What-If analysis — must address all creditable failure modes introduced by the change. The MOC must reference the relevant P&IDs, equipment datasheets, and operating procedures that will be affected. It must identify training requirements for operations personnel. It must link to the permit-to-work that authorizes the physical work. And it must have a defined close-out record confirming that all pre-startup safety review items have been addressed before the changed system is returned to service.

Most of the information in this package already exists in other documents. The P&IDs are in the document management system. The equipment datasheets are in the asset register. The relevant regulatory sections are static. The change description is written by the originating engineer. The hazard review is structured around a defined checklist. The close-out record is a mirror of the pre-startup items.

What currently requires 20 engineering hours on a moderately complex MOC is largely retrieval, formatting, and sequential review — not novel engineering judgment.

What an AI Agent Can Automate

Starting from a change description entered by the initiating engineer, an AI agent can perform the following without human intervention:

Document retrieval and cross-referencing. Given a tag number or equipment identifier, the agent queries the document management system and populates the MOC with references to applicable P&IDs, datasheets, and procedures. This step alone, done manually, typically requires one to two hours per MOC.

Regulatory checklist generation. The agent maps the change type — process parameter, equipment, procedure, organizational — to the applicable PSM or SEMS elements and generates a structured hazard review template pre-populated with the relevant guidewords and checklist items. The engineer does not start from a blank form.

Draft hazard narrative. Based on the change description and the equipment type, the agent drafts an initial What-If or HAZOP narrative identifying the most common failure modes for that equipment category. The draft is not final — it requires review and sign-off by a qualified process engineer — but it reduces the engineer's task from authoring to reviewing and correcting. This is a meaningful reduction in time.

Procedure identification. The agent searches the procedure library for all documents that reference the affected tag numbers or equipment, flags them as requiring review for potential revision, and lists them in the MOC package.

Training requirement identification. Based on the change scope, the agent identifies which operating roles interact with the modified equipment and generates a training requirement list for review by the HSE team.

What the agent cannot do — and should not be asked to do — is make the hazard assessment itself. The determination of whether a specific failure mode is creditable, whether the existing safeguards are adequate, and whether the risk is acceptable requires a qualified engineer applying professional judgment. The agent produces a draft. The engineer signs it.

The Line That Must Be Held

The AI agent is a drafter. The engineer is the assessor. This distinction must be explicit in the workflow design, not assumed. If the MOC system is designed such that an agent's draft can proceed to approval without substantive engineer review, the process safety value of the MOC has been eliminated while the compliance appearance has been preserved. That is a worse outcome than the inefficient manual process it replaced.

In practice, this means the workflow must require an engineer to open every agent-generated section, confirm it against their knowledge of the specific change, and positively attest that they have reviewed it — not just routed it. The time saving comes from the agent doing the retrieval, structuring, and drafting. The engineer's time is then concentrated on the judgment tasks: hazard identification, risk evaluation, and approval authority.

Running in Parallel Before Cutover

The correct approach to deploying an AI-assisted MOC workflow is to run it in parallel with the existing process for a defined period — typically three to six months. During this period, every MOC is completed using both the legacy process and the new workflow. The outputs are compared. Discrepancies are reviewed. The comparison reveals both the gaps in the agent's draft outputs and the instances where the legacy process was producing templates rather than substantive review.

This parallel run period serves two purposes. It validates the agent's output quality before it is relied upon for compliance. And it builds the operational confidence of the engineering and HSE teams who will use the system — a prerequisite for the workflow actually being used correctly once it is primary.

What the Time Savings Look Like

On a straightforward MOC — a control valve setpoint change with no equipment modification — an AI-assisted workflow reduces engineering time from approximately 4 hours to approximately 1.5 hours. The saving is in document retrieval, form population, and initial draft production.

On a complex MOC — a temporary bypass of a safety instrumented function, or a process parameter change that requires a full What-If review — the saving is smaller in relative terms but larger in absolute terms. The agent handles the structural and retrieval tasks; the engineer's effort is concentrated on the judgment-intensive sections that require it. Total engineering time drops from approximately 35 hours to approximately 18 to 22 hours on a well-implemented system.

The risk of getting this wrong is not that the AI draft is incorrect. Engineers are trained to check. The risk is that organizations underinvest in the review step — that the time saving becomes the headline and the quality of the underlying hazard assessment erodes quietly. MOC exists because inadequate change management kills people. The metric that matters is not hours saved per package. It is whether the hazard review is substantively better or worse than what the legacy process produced. That needs to be measured.

Regulators have not yet published detailed guidance on AI-assisted MOC workflows. That will come. In the interim, operators who implement these systems have a documentation obligation: records must demonstrate that qualified engineers reviewed and attested to agent-generated content, not just that the system generated it.

The workflow exists. The regulatory exposure is manageable. The time savings are real, and the discipline required to capture them without compromising process safety integrity is equally real.