Blueprint Law: Blessing, Restructuring & Rollback

The disaster this law exists to prevent

The scenario this was built to stop actually happened: a workflow was fixed and proven in production; one run then failed for an unrelated reason — a bad model response — and self-heal "repaired" the graph by performing structural surgery on a structure that was never broken. Three root causes, all fixed at once: self-heal never checked whether the current structure was already proven; nothing distinguished a runtime-class failure (which no graph edit can fix) from a genuine graph fault; and there was no explicit way to roll a mangled workflow back to what had worked.

Runtime-class failures never reach for a graph edit

classifyRuntimeFailure pattern-matches an error against known runtime/model/credential/quota signatures — an unavailable model, a 429 rate limit, a billing failure, an auth rejection, a context-length overflow, a spawn failure, a network timeout — and returns a plain-language reason when it matches. Deliberately conservative: a false negative just falls through to the normal graph-fault path (recoverable), while a false positive would suppress a repair the graph genuinely needs — so the classifier only ever blocks structural surgery when it's confident the graph isn't the problem.

Blessed means untouchable

The active revision is never autonomously restructured. A legitimate structural repair changes only the current run and creates an unverified candidate. Manual edits and imports follow the same rule. To return to an earlier implementation, restore that historical revision as a new candidate, verify it, and promote it; production continues using the current active revision until promotion completes. There is always an immutable path back to the last thing that was proven to work.

Continue