Does Your Safety Software Manufacture Evidence Against You?

There are two ways safety software can fail you, and only one of them shows up in a product demo. The first is a missing feature: the tool has no module for hot work permits, so you run them on paper. Inconvenient — but your compliance doesn't depend on the vendor, and the inspector doesn't care what brand your clipboard is. The second failure is quieter and much worse: the tool accepts and preserves the record of a non-compliant act. A lockout removal saved with its two verification boxes unchecked. A permit closed with no sign-off from the fire watch that the permit itself said was required. The tool doesn't just fail to help — it generates, signs, timestamps, and stores a document establishing that the step was skipped. Then it exports the list, in a clean PDF, to whoever asks.

Draw that distinction before you evaluate any screen: a coverage gap costs you convenience; an evidence-manufacturing defect costs you the case. The inspector who requests your removal log, or the plaintiff's attorney who subpoenas it, receives a list of unverified removals — compiled by the system you bought to protect you.

At a glance: removal of a lockout device belongs to the authorized employee who applied it; general industry's exception, 1910.147(e)(3), requires a documented procedure — verify absence, attempt contact, inform before return to work — and it is an exception, not a default. Construction is excluded from 1910.147 by (a)(1)(ii)(A); a jobsite controls hazardous energy under 1926.417 for circuits, 1926.702(j) for concrete and masonry equipment, Subpart V for power transmission work, and the general duties of 1926.20 and 1926.21. Whatever standard governs your jobsite, one thing is universal: a record your system saved is a record someone can demand. Safety software that accepts a lockout removal without its verifications, or a permit closure without its required sign-off, creates a timestamped, preserved, exportable record of non-compliance — evidence manufactured by the employer's own compliance tool.

The defect, in one concrete record

Picture the removal screen of a lockout application. Two checkboxes: work area inspected (1910.147(e)(1)), affected employees notified (1910.147(e)(2)(ii)). A crew lead in a hurry taps Confirm with both boxes empty, and the system writes the row: who, when, which energy source — and two verifications left blank. Nothing beeps. Nothing refuses.

Six months later that row is Exhibit C. Not because a worker was hurt that day, but because it proves the system routinely accepted removals without verification — and every other row in the table now reads the same way to a jury. Your records stopped being your defense the moment your tool agreed to store the crew's worst habits with a timestamp on them.

Notice the trap is symmetrical. Software that blocks things the rules don't require (we've written about signature requirements that don't exist) slows your crews for nothing. A tool that accepts things the rules forbid manufactures liabilities for the employer. Getting this right means knowing the text — in both directions.

Who may remove a lock — and what the exception actually demands

The baseline rule of energy control is personal: the device is removed by the authorized employee who applied it. General industry's narrow exception, 29 CFR 1910.147(e)(3), permits removal under the employer's direction "provided that specific procedures and training for such removal have been developed, documented and incorporated into the employer's energy control program" — with three named elements: verify the authorized employee is not at the facility; make reasonable efforts to contact them; and ensure they know the device was removed before they resume work at that facility.

Now picture a lockout module built the easy way: any admin or manager account can remove any worker's lock, unconditionally. One tap. The exception was never implemented as an exception; it became the default behavior, with none of the three elements behind it. The worker whose hands are on the machine has a lock that anyone above them can silently make disappear — and the software keeps a tidy record of every time it happened.

One more distinction worth the ink, because software vendors blur it constantly: 1910.147 does not cover construction — paragraph (a)(1)(ii)(A) excludes construction employment outright. A jobsite has no single lockout standard in its place: circuits are locked and tagged under 29 CFR 1926.417, concrete and masonry equipment under 1926.702(j), power transmission and distribution work under Subpart V, and the rest falls to the general duties of 1926.20 and 1926.21 and to Section 5(a)(1). The 1910.147 program architecture is what much of the industry borrows as recognized practice, and borrowing it is sensible, but a construction citation will cite construction standards, and a record system that stamps the wrong standard on your documents is one more thing to explain in a deposition.

Where HazComFast puts the guards, and how you can check

Each of these holds on the live product, from the screen or through a direct API call that bypasses the screens entirely:

• Applying a lockout requires an active authorization on file. An account with no authorization is refused with the message "Only an authorized employee can apply a lockout", including via direct API call.
• A removal without its verifications is refused by the database. Not warned about. Refused. The detail that separates looking safe from being safe: the constraint fails an empty answer, not only a no. The simplest possible insert, the one that sends nothing at all for those fields, is exactly the one that must not slip through.
• The person who applied the lock can remove it — and a manager who invokes the exception leaves a trail. Removal by someone other than the applier requires a recorded reason and signature, and the actor and the time are written by the server, not typed by the person removing.
• A hot work permit that declared a fire watch cannot be closed without the watch's sign-off — the closure is refused by the database.
• Nobody verifies their own corrective action. The person assigned the fix cannot also be the person who signs off that it worked — the system takes the verifier from the authenticated session and rejects the overlap.

The pattern across all five: the guard lives in the database, so it holds against a direct API call, an offline sync, and a foreman's hurried tap alike. A guard that lives in the screen's JavaScript holds against none of those — and "the screen wouldn't let me" has never impressed anyone with a subpoena.

Run this test on whatever you use today

Fifteen minutes, no vendor call required:

1. Save a lockout removal with the verifications unchecked. Accepted? Every removal in your history just became questionable.
2. Close a permit that requires a sign-off, without the sign-off. Accepted and timestamped? That's a manufactured admission.
3. Have an assignee verify their own corrective action. Accepted? Your CAPA log documents self-graded homework.
4. Ask who can remove a lock that isn't theirs — and what the system records when they do. "Anyone with a manager role, and nothing" is the wrong answer twice.
5. Check what standard your records cite if you do construction work. If every lockout record says 1910.147, see the FAQ above.

If your current system passes all five, keep it and shake your vendor's hand. If it doesn't, at least you now know what your export will say before someone else reads it to you.

The hub & related: Lockout/Tagout hub · The Complete LOTO Guide · Does 1910.147 Apply to Construction? · Electronic Signatures on OSHA Records · Legal Hold & Record Locking · The Citation Defense Package

Sources & verification: removal by the applying employee and the three-element exception per 29 CFR 1910.147(e)(3), and the construction exclusion per 1910.147(a)(1)(ii)(A), both verified against the CFR text 2026-08-27; construction circuit lockout per 29 CFR 1926.417 and concrete and masonry equipment per 1926.702(j)(1), re-read on the eCFR on October 6, 2026; record production per 29 U.S.C. 657(b) (govinfo) and 29 CFR 1904.40(a). Product behavior verified on the live product on August 22, 2026, including direct API calls, and the database guards re-read in the product's code on October 6, 2026. This article describes documentation risk, not legal strategy. General guidance, not legal advice.