Heal What You Can Prove.

Everyone wants self-healing AI code. Almost nobody asks the load-bearing question: what is the healer allowed to touch? In my stack the answer is written down, and the most important part is the never-heal list. A system that can repair anything can also break anything, fluently, at 3 a.m., in your own voice.

So I build healers the opposite way from the demos: the healing layer is the dumbest component in the system, on purpose.

Why should the healer be dumb?

Because it runs unattended, and unattended plus probabilistic equals unaudited changes to your own record.

The split that keeps it safe has three tiers. Models may propose: they draft, suggest, and generate under review. Deterministic healers may apply: compiled patterns with exactly one degree of freedom, the value being substituted. Humans decide meaning: any change that alters what a sentence or a schema claims. The intelligence in the system lives in deciding what is healable. The healing itself is a find-and-replace with a test suite.

My sibling post covers the runtime half of this, the bounded repairs and why self-healing is a euphemism unless you count the heals. This one is about the stranger half: systems that rewrite their own artifacts, code and prose included.

A model that can heal anything can plausibly break anything. Plausibly is the problem.

What does artifact healing look like in production?

My blog is the working example, because it has a real drift problem: a post written today publishes months later, and every figure in it describes a system that keeps moving.

So every live figure in a queued post is registered with the exact phrasings that carry it. A weekly job pulls the live numbers from Orbyt's generated stats payload, the same artifact its public build log renders, compares prose against source, and rewrites mechanical drift in place. The run commits through the full test gauntlet or not at all.

The receipt that justifies the machinery: three days after one batch was written, 42 phrases across 9 queued posts were already stale. The failure corpus they cited had grown from 49 incidents to 51, the portfolio from 531,000 lines to 532,000. Three days. No editor catches that, which is why the data layer under the prose exists at all.

And one design detail I consider non-negotiable: a pattern that matches nothing fails the test suite. A dead pattern reads as coverage while checking nothing, and a check that quietly stopped checking is worse than no check, because it spends your trust.

What belongs on the never-heal list?

Everything whose change is a decision rather than a substitution. Mine has four entries, each with a reason.

Published posts. A live post's numbers are dated claims. Healing them silently rewrites history, and a site that rewrites its history teaches readers to trust none of it. Drift in published posts is reported, and left.

Curated claims. A handful of my figures are deliberately kept consistent with external profiles that cite them. A machine "correcting" one would retire a number other sites reference. Consistency with the world outranks consistency with the payload.

Meaning-bearing numbers. My governance ladder holds at a stage, and the sentences around that number explain which criteria are unmet. If the ladder advances, that is a different claim about the company, not a substitution. The healer flags it and stops.

The spec itself. The healer may restore artifacts to what the source of truth says. It may never edit the source of truth. The same line my runtime repairs respect, restore the standard, never move it, holds harder here, because prose is where moved standards hide best.

Where else does the same constitution apply?

Anywhere a system retries its own failures. My Stripe webhook layer runs the identical three-way split, in money instead of prose.

Across the 16 event types that layer handles, retryable failures release their idempotency dedup deliberately, so the retry actually reprocesses and the mirror heals itself. Poison events, the ones that can never succeed, are quarantined instead of retried, because healing them is impossible and pretending otherwise risks the whole endpoint. And nothing in that directory changes without a named human instruction, because the money path sits on the never-heal list of the entire company.

Healing, flagging, quarantine. Every honest self-repairing system I have built converges on those three lanes, and the guards that watch them are what make the lanes real. Materials scientists build self-healing materials around embedded repair agents that respond only to specific damage. Nobody embeds an agent that redesigns the bridge.

What to do Next

Write your never-heal list before your next automation ships. What may this system not touch, ever, on its own? If the list is empty, the system is not ambitious. It is undesigned.

Then check the degrees of freedom on everything that rewrites unattended. One, the substituted value, is a healer. More than one is an author, and authors need review.

Last, hunt your dead checks. Find every pattern, alert, or validation that has matched nothing for months and make silence a failure. The unhealed error will announce itself eventually. The check that stopped checking never will.

The measure of a self-healing system is not how much it can repair. It is how precisely it knows what it may not.

Related reading:

• Self-Healing Is a Euphemism. the runtime half: bounded repairs, counted

• The Money Path Is a Protected File. the same constitution, applied to money

• Your Linter Was the Prototype. code that repairs code, and its limits

• Your Tests Are the Spec Now. the source of truth healers restore toward

---

Originally published on orbytlabs.ai on Sep 13, 2026.