Four steps, and none of them are yours.

Start from the raw Make message, or just the symptom. Both work — they only change how narrow the diagnosis can get.

The raw message is better than a summary, because the module number and the bundle index in it are what let the analysis find the failing run in your execution data. If you only have « it stopped writing rows this morning », that is still a valid starting point.

What each extra piece buys you

• The blueprint (Scenario → Export blueprint) turns guessing into reading. Without it, the analysis only has the error text — the same thing a general assistant has.
• Execution data for the failed run is what upgrades a cause from likely to confirmed.
• Context — when it last worked, what you changed — often cuts the candidates in half on its own.

This is the step that makes the difference. The error names the module that threw it; that module is usually the victim, not the culprit.

So instead of parsing the wording, FixScenario rebuilds the neighbourhood of the failure from your blueprint: which modules feed the one that broke, what shape each of them promises, and what they actually produced on the run that failed.

What it looks at

• The chain upstream of the failing module, module by module.
• The mapping on the failing field, and whether the property it points at exists in the real output.
• The resolved values in the failed bundle — empty, wrong type, or absent.
• Filters and routers between them, because a bundle blocked upstream looks exactly like a bundle that was never produced.

A general assistant restates the error because the error text is all it has. This step is why the answer can be different.

You receive possible causes, available evidence and checks. Precise field changes are provided only for supported cases with sufficient evidence.

Confirmed or likely

Confirmed means the execution data shows it directly. Likely means the blueprint supports it but nothing proves it. A confirmed observation is not a verified repair. Test any proposed change in Make.

Evidence, not assertion

Every claim points at the field, the bundle or the module it came from. Anything that cannot be traced is labelled as an inference rather than stated as fact.

The change itself

The current mapping and the corrected one, side by side, in the form you can copy straight into Make. Then the steps to apply it, numbered, in the order you would actually click them.

Fixing the field gets the scenario running again. It does not stop the same failure from coming back after the next edit upstream — and most Make failures are repeat offenders.

So every diagnosis ends with what to change so it does not come back.

What that usually looks like

• Re-run the trigger after any change to the upstream data shape, so Make relearns the structure instead of holding a stale one.
• Add an error handler where a third-party outage is plausible, rather than letting a 503 kill the run.
• Key writes on an id from the payload, so a retried webhook delivery cannot duplicate a row.
• Pick the field from the output picker instead of typing the path, so a rename breaks loudly rather than silently.