How babysitter's process-as-code philosophy changed my enforcement model

[lee-fuhr]

I maintain an engineering methodology called the Build Bible for my Claude Code setup, and yesterday I had to trash an entire project because every single principle in it was advisory. Written in markdown. Relying on the agent to read it, remember it, and follow it while deep in a build. The principles were right, the enforcement was nonexistent.

A colleague pointed me to babysitter, and the process-as-code idea immediately filled the gap I'd been staring at. I'd been treating governance as documentation. You're treating it as runtime constraint. That's the difference.

The question that keeps nagging me now: "If the agent ignored this instruction, what would prevent the violation?" For almost everything in my system, the answer was nothing. Rules existed, but enforcement didn't.

So I rebuilt around that idea. Bumped the Bible to v2.0.0 with a new principle about enforcement levels (advisory, blocking, deterministic), an enforcement contract where every principle declares its current level and target level, process definitions with step-boundary enforcement for critical workflows, and an event journal for orchestration state. The whole thing shifted from "the conductor follows the rules" to "the system won't let the conductor skip the rules, because the conductor will drift under pressure."

Wanted to share because it felt like a genuine case of your ideas landing in a system you probably didn't anticipate. Good work on this.