What an Override Does and How Long It Lasts
Why this matters
Most systems that have been in service more than a few years are running partly on overrides nobody remembers applying. Each one was reasonable on the day: a customer needed heat, a part was on order, a tech needed to prove something. What makes them expensive is not what they do. It is that almost none of them expire, most of them are invisible from the screen where the complaint will eventually appear, and the next tech reads their effect as the equipment's normal behavior.
This card is about what an override leaves alone, which is nearly everything, and about the one property that separates a harmless one from a permanent undocumented redesign: how it ends.
The one thing an override changes
An override substitutes a value for a decision. That is its entire function.
Somewhere in a control loop a controller computes an output, and an override replaces that computed number with one a human chose. Everything upstream of that substitution and everything downstream of it operates exactly as before. The measurement is still made the same way, the actuator still obeys, the process still responds.
Understanding this as narrowly as it deserves is what stops an override from being mistaken for a repair, which is the single most common misuse.
Four things an override does not touch
It does not change what the sensor reports. A reading that was wrong before the override is wrong after it. Overriding an output because the input is untrustworthy leaves an untrustworthy input in service, feeding every other piece of logic that reads it, including logic on other equipment.
It does not satisfy or remove a protective device. A limit, a pressure switch or an interlock in the energy path keeps operating regardless. An override that appears to have no effect on a piece of equipment usually means a protective device is holding it, and that is the correct behavior, not a fault in the override.
It does not fix the condition that caused someone to reach for it. The reason the loop could not hold its target is still there, still developing, and now unobserved. An override applied to a symptom converts a visible problem into an invisible one at no charge.
It does not record why it was applied. Almost no system stores an intent. It stores a value and, if you are lucky, a timestamp and a user name. The reasoning that made the override defensible on the day dies with the memory of the person who applied it, usually within a month.
The one thing it does that nobody expects
On many systems, putting a point in manual suppresses that point's own alarming.
This is a sensible design decision - a point a human is deliberately holding should not generate a continuous fault - and it has an unfortunate consequence: the mechanism that would have told you the override exists is turned off by the act of applying it. An overridden loop sitting at an extreme value for a year produces no alarm, no trend excursion that looks abnormal, and nothing on a summary screen. It looks like the healthiest point on the system.
That is why override discovery is a deliberate sweep rather than something you wait to be told about.
The expiry rule is the whole risk
Sort every override you meet by how it ends. That column predicts almost everything else about it.
| Class | What it substitutes | How it ends | How you find it |
|---|---|---|---|
| Physical hand switch on a starter or actuator | The entire control decision, at the hardware | Only when a person moves it back | By looking at it, in person |
| Controller point placed in manual or out of service | The computed output for that point | Only on an explicit release | A flag on the point, rarely on the graphic |
| A claim on a command priority level | Everything ranked below it | Only when that writer relinquishes the level | By reading the point's priority table |
| Timed override, such as an occupancy bypass | The schedule, for a stated duration | On its own timer | It announces itself and then stops |
| A parameter moved "temporarily" - a setpoint, a limit, a delay | Nothing; it is now the configuration | Never, because nothing marks it as temporary | Only by comparison against a recorded baseline |
Four of those five have no expiry at all. The timed one is the exception, and it is the only class that behaves the way people assume overrides behave generally.
The last row is the one worth dwelling on, because it is not usually counted as an override at all. A setpoint moved from one value to another leaves no trace that distinguishes it from the value the system was commissioned with. There is no flag, no color, no list it appears on. It is indistinguishable from design intent, permanently, unless somebody wrote down the number it replaced.
The class that is not an override at all
A jumper across a limit, a pressure switch or an interlock is not on the table above and does not belong in this category. It is a removed protection, and it stays removed for everything, not just for the condition that prompted it.
Where a protective device is what stands between you and a running machine, the work is to establish why it opened, by measuring the quantity it watches against its stated trip point while the machine runs. That measurement is the job. Jumpering it out reaches an end state nobody would defend, and replacing a device that operated correctly reaches the same end state one step slower and with a part number on the invoice. Both leave a machine running past a boundary somebody set for a reason.
If the measurement requires an open enclosure, de-energize the line-voltage supply, lock and tag it, and prove dead first under 29 CFR 1910.333(b)(2), with live-dead-live per NFPA 70E-2021, 120.5. Where the reading genuinely cannot be taken dead, that is the narrow troubleshooting allowance at 29 CFR 1910.333(a)(1), taken with meter and leads rated for the circuit's measurement category and available fault current plus the shock and arc-flash protection the assessment calls for. Where the device guards stored energy - a spring, an accumulator, a pressurized vessel - that energy is isolated and relieved under 29 CFR 1910.147 before your hands are inside its reach.
Worked example: a sweep of one system, and what the ages said
One air handler and the terminal equipment it serves, swept in an afternoon by walking the equipment and reading each point's own flags.
Six overrides found:
- A supply fan starter with its hand-off-auto switch in HAND. No date. The commissioning photos from three years ago show it in AUTO, so it is younger than that and nothing narrows it further.
- A chilled water valve point in manual at 100 percent, with a last-change timestamp 14 months old.
- A priority level claimed by a routine that was removed in a software upgrade eight months ago. The level is still occupied and the writer no longer exists.
- An occupancy bypass with 45 minutes remaining on its timer.
- A discharge setpoint reading 60.0 F where the sequence of operation says 55.0 F, with no record of the change.
- A jumper across a high-limit switch.
One of the six has an expiry. The occupancy bypass will end by itself in 45 minutes. The other five are permanent until a person acts, and three of those five would not have appeared on any screen anyone routinely looks at.
Work the second one through. A valve held at 100 percent for 14 months, on a unit that runs about 12 hours a day, is roughly 426 days at 12 hours, about 5,100 hours of full flow on a valve that should have been modulating. If its intended average position over that period was around 45 percent, the valve delivered on the order of 2.2 times its intended average position for the whole stretch. That ratio is the honest way to state it: the position is known, the flow is not, because flow through a control valve is not linear in position and the relationship depends on the valve's characteristic, which is a datasheet property rather than something to assume.
No alarm fired in 14 months. The point was in manual, so its own alarming was suppressed, and the loop it belonged to never reported an error because the loop was not being asked to hold anything.
What the ages actually tell you. Item 3 is the interesting one and it is not the oldest. A priority level occupied by a writer that no longer exists means every routine ranked below it has been inert for eight months, including the schedule. Somebody has almost certainly been complaining for eight months that the schedule does not work, and somebody else has almost certainly been unable to reproduce it.
Item 5 is the one that will still be there in five years. A setpoint of 60.0 F against a documented 55.0 F is a 5.0 F difference with nothing on any screen marking it as anything other than the design value. The only way it was found at all was by reading the sequence of operation and comparing. Nobody sweeping override flags would have seen it, because it is not flagged as one.
Item 6 stops the sweep. A jumpered high limit is not logged and scheduled for later; it is established why that limit was opening, before the machine is left running, and the jumper comes out.
Where an override is the right answer
This card is not an argument against overrides. Three uses are legitimate and one of them is a diagnostic technique.
Proving a device during commissioning or troubleshooting. Commanding an output by hand is how you separate a command problem from a feedback problem, and it is unavoidable. The condition is that it is reversed before you leave and that the reversal is confirmed, not assumed.
Keeping a customer served while a part is on order. Defensible where the overridden state is safe, where the protective devices are all intact and operating, and where the override carries a date by which it will be removed. Without that date it is not a bridge, it is a new design.
Isolating a writer while you find which controller is in charge. A sibling card covers that procedure; each perturbation in it is an override, and each one is reversed as it is finished with.
What all three share is that somebody knows the override exists, why it exists, and when it ends. Those three facts are what separate a tool from a liability, and a sibling card covers how to record them so they survive the drive home.
How to find the ones nobody logged
Compare the commanded value to the computed value on every point that has both. A persistent disagreement is an override, whatever it is called locally, and this finds the ones with no flag.
Look for points that do not move. A modulating output sitting at exactly the same value across a week of changing conditions is either overridden or dead, and both are worth knowing. This is the cheapest single sweep available and it can be done from a trend without visiting the site.
Walk the hardware. Hand switches do not appear on any system screen, ever. There is no substitute for looking at them, and a photograph of each one in its correct position is worth taking while you are there.
Compare live parameters against the sequence of operation, not against memory. This is the only method that finds a moved setpoint, and it is why an accurate baseline record is worth more than any discovery technique.
References
- 29 CFR 1910.333(a)(1) - live parts de-energized before work, and the narrow conditions permitting energized troubleshooting
- 29 CFR 1910.333(b)(2) - lockout and tagging for work on electric circuits and equipment
- 29 CFR 1910.147 - control of hazardous energy for mechanical isolation and stored energy
- NFPA 70E-2021, 120.5 - process for establishing and verifying an electrically safe work condition
- Manufacturer documentation for the point's manual and priority behavior, its alarm suppression under manual, and the control valve's flow characteristic
- See related: Interlocks and Why They Are Not Control; How to Find Which Controller Is Actually in Charge; How to Document a Control Change So the Next Tech Can Undo It