Interlock

Two crews. One power line. If both are told it's safe to work, someone dies. Interlock is the AI that tracks who has shut off what, and refuses the second request before it's granted.

Comment

Inspiration

Before anyone repairs a power line, a pipe, or a heavy machine, someone shuts it off and physically locks the switch so it can't be turned back on while a person's hands are inside it. This is called a permit-to-work, or lockout-tagout, and it exists because people have died when the wrong equipment got re-energized at the wrong moment.

The thing that actually kills people isn't a missing form. It's two crews holding different beliefs about the same machine: one crew working on a feeder they think is dead, another removing a lock they think is theirs. I kept coming back to a detail that makes this hard for computers. Crews don't talk in equipment serial numbers. They say "the north feeder," "the valve by the pump house," "the breaker we locked last Tuesday." Matching that everyday language against the real record of who holds what is exactly the kind of judgment an agent can do and a paper form cannot. That gap is where Interlock lives.

What it does

Interlock is an AI safety gatekeeper for dangerous maintenance work. Its only job is to make sure two crews never both believe they've locked the same asset. It does three things:

  1. Translates plain language into the exact machine. A worker says "isolating the north feeder"; Interlock figures out which specific asset that refers to.
  2. Checks its memory for whether anyone already holds that lock.
  3. Grants or refuses. If it's safe, the permit is issued. If someone already holds it, or if Interlock is unsure, or its memory is unreachable, it refuses and work stops. A human authority still signs off; Interlock is the gatekeeper, not the boss.

The core rule: it fails closed. An agent that guesses which equipment is locked isn't a degraded safety tool, it's a dangerous one. So when in doubt, the answer is no.

Here's where it earns its keep. Three situations it's built for:

The same line, two names. Alex locks "the north feeder." Minutes later Sam requests "NF-12," the same power line by its official code. Without Interlock, Sam assumes it's free and starts working on a line Alex believes is safely his. Interlock recognizes the two names point to one asset, sees Alex's lock, and refuses Sam, naming who holds it.

Two requests in the same instant. Two crews on opposite ends of a plant request the same valve at nearly the same second. A sloppy system could tell both of them yes, and now two crews each think they're alone on it. Interlock guarantees exactly one wins; the other is automatically refused, and both the approval and the refusal are permanently recorded.

The system loses connection. Mid-shift, Interlock can't reach its record of who holds what. Instead of guessing and risking a fatal mistake, it refuses and tells the worker to wait until it can confirm safety. Annoying, but alive.

How I built it

The whole thing hinges on one idea: the moment a permit is granted has to be a single, all-or-nothing operation, so no other request can sneak in halfway through.

Inside that one operation, two mechanisms run together. The first is fuzzy matching, turning "the north feeder" into the set of real assets it could mean. This handles scope: what are we even talking about. The second is an exact lock, a hard record that says "this asset is held, and only one crew can hold it." This handles correctness: is there actually a conflict. The fuzzy match figures out what you mean; the exact lock decides whether you're allowed. Keeping both in the same indivisible step is what closes the dangerous gap where a second request could slip in between "figuring out what you mean" and "claiming the lock."

I used CockroachDB as the memory layer because that all-or-nothing guarantee is its whole reason for existing, and because it keeps running even when a server dies, which for a safety tool isn't a nice-to-have, it's the point. On top of that I wired in AWS for the AI language understanding, the request handling, and permanent storage of the audit records.

Challenges I ran into

The hardest lesson: fuzzy matching can never be trusted to decide a conflict. Two requests can find similar-sounding equipment and still not collide unless they try to claim the exact same lock. Early on I leaned too hard on the "smart" search to catch conflicts, and it would've let dangerous edge cases through. The fix was to split the job: let the smart search decide scope only, and let a plain, strict lock decide correctness. That separation is the single most important decision in the project.

The other real challenge was resisting the temptation to make the demo flashier by letting the AI write directly to the safety records. I deliberately kept the write path locked behind a strict, least-privilege account and left the AI's direct database access read-only. For a tool whose job is safety, the restraint is the feature.

Accomplishments that I'm proud of

  • A safety tool that refuses correctly, including refusing itself when its own memory is unreliable.
  • Proving the two-requests-at-once case: fire two claims at the same asset in the same millisecond and get exactly one lock, one refusal, and a full record of both.
  • Every grant, every refusal, and every escalation is permanently logged, so an inspector can reconstruct exactly what happened and why.
  • Using my security background to build real access control and audit trails, not just a working demo.

What I learned

I learned the difference between an app that stores memory and an app where memory is the product. If you could swap the database for a simpler one and nothing broke, it was never really a memory project. Here, the entire safety guarantee rests on the database's ability to make one indivisible, conflict-proof decision. Remove that and the tool becomes dangerous. I also learned that in safety-critical software, the most important behavior is often the refusal, and the best engineering decision is frequently the capability you choose not to give the AI.

What's next for Interlock

  • Voice input, so crews can request permits hands-free in the field instead of typing.
  • Integration with real lockout hardware, so the digital record and the physical lock stay in sync.
  • A certification path. Real deployment in industry would need formal safety review measured in months, treating Interlock as a custodian inside an existing permit-to-work system rather than a replacement for one.
  • Multi-site coordination, so isolation state stays consistent across facilities and regions, not just one plant.

Built With

Share this project:

Updates