A rule you can still break isn't built yet
I had a separate AI, a different model than the one I build with, review my whole operation with one instruction: find where reliability leans on me remembering. The fix, every time, was to move the rule out of my head into something that enforces it.
I ran an outside AI over my workspace as an adversarial reviewer, looking for where trustworthiness depended on memory and discipline rather than enforcement. It found a privacy rule that was policy-only, hand-kept counts that had drifted, and a health check I ran from memory. The repairs turned each into a mechanical control, and I looped the reviewer back over them three times until it converged. The honest limit: the checks report and catch drift; they don't yet self-repair, and I say which rules still ride on me.
A system gets more reliable as it grows only if its rules get harder to break. Mine were drifting the other way. The workspace I run on had reached the point where a lot of what kept it trustworthy lived in my head: a privacy rule I'd written down, a set of counts I re-typed by hand across several documents, a health check I ran when I remembered to. Each is fine on a good day. None of them is a control. A control is something the system can't get around whether or not I'm paying attention.
So I did something I'd suggest to anyone running an operation on AI. I had a different model, one I don't build with, go through the whole thing cold with a single instruction: find where reliability depends on me remembering rather than on something enforcing it. The verdict it handed back named the pattern exactly. Too many important truths were maintained by ritual and memory rather than enforced by scripts.
Three rules that only existed on paper
None of what it found was exotic. A privacy boundary that lived only as a written contract: the document said certain files must never be published, but nothing in the code that builds my searchable index actually checked. A file marked private could have been swept in and sent off to be embedded, and I'd have learned that afterwards, if at all. Counts I kept by hand, which had quietly drifted out of agreement with each other. And "is the workspace healthy?" being a question I could only answer by running a handful of checks in the right order, from memory, if I thought to.
Moving each one out of my head
The repair in every case was the same shape: take the thing I was trusting myself to do, and make the system do it. The privacy rule now lives in the code that builds the index; a file marked private or sensitive is refused, out loud, with the reason logged. "Is this healthy?" is now one command that checks the state I used to eyeball, and it runs on its own at the start and end of every working session. The counts got a checker that catches the numbers I used to trust my eye on. And a separate scan watches for sensitive data slipping into anything headed outward.
The loop was the point, not the review
Then the part that made it hold. I gave the same outside reviewer the repairs and asked it to try again. It found more: a checker that flagged its own documentation as a problem, and a fault that only surfaced when nothing was running. I fixed those and sent it back. Three rounds, until it stopped finding things. A single review is a snapshot; the loop is the method.
How far this actually goes
I'll be exact about the limit, because "I made my system self-checking" is the better-sounding claim and the less true one. The health command reports; it doesn't repair. A couple of the counts still reconcile by hand. What changed isn't that everything is automatic now. It's that I know precisely which rules the system enforces and which still ride on me, and the second list is short and written down where I can watch it shrink. The test of a rule isn't whether you wrote it down; it's whether the system can still break it. Every rule I could still break by forgetting is one I'd only described, not built.