The trigger: drift
Every response from every connected system flows through the Runtime Monitor. It doesn't just look for HTTP errors — it compares the shape of each response against the registered mapping. When a field is renamed, removed, or added, the data has drifted from what the connector expects. That divergence is the signal.
The response: re-inference and rebuild
On detecting drift, the engine re-enters the same loop that built the connector in the first place. It re-introspects the live system, re-infers the schema, maps the new shape back onto the Universal Data Model, regenerates the connector, and runs it against the live system to confirm it passes. Only then does it swap the new connector in.
The IT director finds out after the fact, from a log entry — not as a support ticket.The honest part: escalation
Self-healing isn't magic, and we don't pretend it is. Each connector has a configured attempt budget. If the engine genuinely can't resolve a change within that budget, it stops, suspends the connector, and escalates — with a precise, actionable diagnostic bundle, not a generic failure. Auth failures, for instance, are never retried blindly, because credentials are managed outside the engine.
The result is that the routine, constant churn of API change — the stuff that generates most integration tickets — disappears into automated recovery, and a human only gets involved for the genuinely novel cases that deserve attention.