A temporary management of change is the version of MOC used when a change is meant to be undone. Some changes are permanent - a new pump, a revised limit - and stay in place until the next change. But plants also make changes they intend to remove: a jumper to keep running while a part is on order, a bypassed interlock during commissioning, a spool piece standing in for equipment that is out for repair. A temporary MOC governs exactly these, and its defining feature is that it carries an expiry date and a requirement to put things back the way they were. Its whole purpose is to make sure a temporary fix does not quietly become permanent.
Temporary MOC in one line: A temporary management of change is a time-limited MOC for changes intended to be reversed, such as jumpers, temporary bypasses, or defeated interlocks. It carries an expiry date and a required reversion to the original condition, and the live temporary change must be tracked so it is removed on time rather than silently becoming a permanent fixture.
A temporary change is one a facility deliberately puts in with the intention of taking it out again, and that intention is precisely what makes it dangerous if it is not managed. A jumper wired to keep a system running past a failed component, a spool piece bridging a gap where equipment has been removed for repair, a defeated interlock that lets commissioning proceed - each is an acceptable, considered deviation for a limited time. The problem is that the very things that make a temporary change temporary, the plan to reverse it, live entirely in someone's head or on a form, not in the physical plant. The hardware itself has no idea it is only supposed to be there for a week.
This is why a temporary MOC exists as its own discipline rather than being folded into ordinary change control. A permanent change ends its life the moment it is implemented and documented; a temporary change is not finished when it is installed - it is finished only when it is removed and the original condition is restored. A general MOC process that treats implementation as the end point leaves temporary changes with no built-in mechanism to bring them back. The temporary MOC adds the two things a temporary change specifically needs: a hard end date and an explicit obligation to revert.
The failure this guards against is one of the most common in a plant: the temporary fix that nobody ever removes. A jumper installed to get through a night shift is still there a year later. A bypassed interlock defeated for testing is never re-enabled and is discovered only after an incident that the interlock would have prevented. These are not exotic failures; they are the ordinary consequence of a temporary change losing its expiry and its reversion because nothing was tracking either. The temporary MOC discipline exists to keep that from happening as a matter of routine rather than luck.
The expiry date is the heart of a temporary MOC. Every temporary change is approved with a defined end date by which it must be removed or, if it is genuinely still needed, formally reviewed and re-approved to continue. That date is not a suggestion - it is the mechanism that forces someone to look at the change again rather than letting it drift on indefinitely. If the underlying need still exists at expiry, the honest options are to extend the temporary change through a fresh review, or to recognize that a change lasting this long is really permanent and should be converted to a permanent MOC with the full review that implies.
The reversion to original is the other required element: an explicit description of what putting things back looks like, so the change can be reliably undone by whoever removes it, not just by the person who installed it. Reverting a jumper means removing the wire and confirming the original protection is restored; reverting a defeated interlock means re-enabling it and verifying it functions; reverting a spool piece means reinstalling the proper equipment. Because the person removing a temporary change months later may not be the one who put it in, the reversion has to be documented clearly enough to stand on its own, and the removal has to be verified rather than assumed.
Together, the expiry and the reversion turn a temporary change from an open-ended liability into a controlled, bounded deviation. The change is allowed, but only for a known time and with a known way home. This is what lets a facility use temporary changes freely and safely - to keep running past a failure while a part is sourced, to enable commissioning work, to bridge a repair - without accumulating a hidden backlog of defeats and jumpers that no one remembers the reason for. The discipline is what keeps temporary genuinely temporary.
Many temporary changes live in or affect the control system - a bypassed interlock, a suppressed alarm, a forced point, a setpoint moved to accommodate a workaround - which makes the control room the natural place to track them. The danger of these control-system temporary changes is that they are invisible unless something surfaces them: a defeated interlock looks exactly like an enabled one on a schematic, and a forced input reads like a real one unless it is flagged. A cloud SCADA platform such as Merobix can maintain a live view of active bypasses, forced points, and suppressed alarms, so the temporary changes riding in the control system are visible to the operator rather than buried in the configuration.
That visibility is what makes expiry tracking actually work in practice. A list of temporary changes filed in a binder is easily forgotten; a live register that the control room can see, with each temporary change and its expiry surfaced against the running plant, keeps the pressure on to remove them on time. When an operator can see at a glance every interlock currently defeated and every alarm currently suppressed, along with when each is due to be reverted, the temporary changes cannot slide quietly into permanence the way a paper list allows. The control room becomes the place where the expiry dates are answered rather than ignored.
For remote and unmanned sites, this tracking is especially valuable, because there is no one standing at the equipment to notice a temporary change that has overstayed its welcome. A central dashboard that shows every live temporary change across a fleet of sites, flags the ones approaching or past their expiry, and confirms when each has been reverted is often the only practical way to keep control of temporary changes across a dispersed operation. The reversion still has to be done in the field, and often physically, but a control system that keeps the live temporary changes and their expiries in plain view is what stops a fleet's worth of jumpers and bypasses from accumulating unseen.
A normal MOC governs a permanent change and is considered complete once the change is implemented and documented. A temporary MOC governs a change that is meant to be reversed, so it adds two things a permanent change does not need: an expiry date by which the change must be removed or re-reviewed, and a required reversion to the original condition. A temporary change is not finished when installed - only when it has been removed and the original state restored.
The expiry date is the mechanism that forces a temporary change to be looked at again rather than drifting on forever. Without it, a jumper or a defeated interlock installed for a night shift can still be in place a year later because nothing ever prompted its removal. At expiry, the change must be removed, or if still needed, formally re-reviewed to extend it, or converted to a permanent MOC. The date is what keeps a temporary fix from silently becoming permanent.
Temporary MOCs handle changes deliberately intended to be reversed, such as jumpers to keep running past a failed component, temporary bypasses, spool pieces bridging removed equipment, and defeated or bypassed interlocks during commissioning or maintenance. Each is an acceptable deviation for a limited time but carries a real hazard if left in place. The temporary MOC tracks these live changes with an expiry and a reversion so they are removed on time rather than forgotten.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.