What This Looks Like
A prompt, workflow, structured output, parser-facing response, or generated artifact worked before, but starts failing after the model, mode, runtime, or product behavior changes. The user may see different formatting, missing structure, new wording, parser failures, changed refusal behavior, or different assumptions after the change.
Why It Matters
Model changes can break working workflows even when the user did not change the prompt. If the output contract depends on behavior that shifts across versions or modes, downstream systems may fail without an obvious local cause. Users need to distinguish prompt failure from compatibility drift.
Structural Signal
The output contract remains expected by the user or workflow, but the model behavior that produced it has changed. The issue is not simply that a new output is different; it is that the new behavior no longer fits a previously working compatibility envelope.
Common Triggers
- A model update changes formatting, reasoning style, or default structure
- The runtime switches models or modes without clear notice
- Prompt examples no longer constrain the new model the same way
- A parser expects old output behavior
- Product changes alter tool use, refusal behavior, or response structure
- A workflow depends on undocumented model behavior
When to Use This Issue
Use this Issue when output that previously worked begins failing after a model, mode, runtime, or product behavior change.
When Not to Use This Issue
Do not use this Issue when the prompt, schema, or workflow changed at the same time and is the clearer cause. Do not use it for ordinary output variation unless the model or runtime change is central to the break.