/ platform · monitor & heal
The upstream API changed.You should not find out from a failed job.
Inferrex watches the systems it understands for structural change, re-reconciles what moved, and corrects the integrations that depended on it — with a record of what changed and what it did about it.
/ the problem
A breaking change is usually discovered by its consequences.
A field is renamed. A type becomes nullable. An enum gains a value nobody downstream handles. None of these announce themselves, and most are not breaking changes from the publisher's point of view — they are ordinary product work.
Downstream, the first signal is a failed job at 3am, or worse, a job that succeeded and moved the wrong value. The gap between the change and the discovery is where the cost sits: not in the fix, which is usually small, but in the hours before anyone knew there was one.
/ the approach
Detect the change, re-reconcile, then correct what depended on it.
Because Inferrex holds the structure and the meaning of a system separately from the integrations that use it, a change can be handled where it happened rather than in each thing that consumed it.
Notice
The comprehended shape of a system is compared against what it now publishes. A difference is an event, not a support ticket.
Re-reconcile
The changed structure goes back through mapping. A rename that preserves meaning is resolved; a change that alters meaning is escalated rather than absorbed.
Correct
Integrations reading the canonical layer inherit the correction. They were never coupled to the old field name in the first place.
Record
What changed, when, what was inferred, and what was done. Self-healing that cannot be audited is indistinguishable from silent data corruption.
/ the limits
Some changes are not recoverable, and should stop rather than heal.
Healing is only honest where the meaning survived the change. A field renamed is recoverable. A field whose semantics changed while its name stayed the same is not, and treating it as recoverable would produce exactly the failure this page exists to prevent — a green pipeline moving wrong values.
So the design rule is that an unresolvable change stops and reports. A system that quietly does its best with a change it did not understand is worse than one that halts, because the first is discovered months later in a number nobody can explain.
Monitoring is not the same as understanding
Point it at an API that changes often.
The value of this is proportional to how unstable the upstream is, so the best test is your least stable dependency.