Breaking change signal

Check whether a pull request changes public behaviour that existing users depend on.

F@f

Problem

Breaking changes slip into minor releases because nobody flagged them during review, and users find out on upgrade.

Goal

Flag likely breaking changes before merge, so they get migration notes and land in the right release.

Input / state

PR description and a summary of changes to public APIs, config or CLI flags.

description
PR title and description.
public_surface_changes
Changed exports, endpoints, config keys or flags, extracted in code.

Decision question

NoulQuestion key breaking_change

Does this change alter public behaviour in a way that could break existing users?

What counts as yes and no

  • trueRemoves or renames public APIs, flags or config, changes defaults, or changes output formats users rely on.
  • falseAdds new behaviour, fixes bugs without changing contracts, or only changes internals.

Allowed outcomes

Decided in your code from the answer and its confidence. Thresholds are yours to set and test.

  • Likely breakingProbability of yes is above your upper threshold.
  • UnclearProbability falls between your two thresholds.
  • Not breakingProbability of yes is below your lower threshold.

Example scenarios

Predefined demonstrations. No model is called; the outcome shown is an illustrative judgment.

Example state

{
  "description": "Rename --out to --output",
  "public_surface_changes": [
    "CLI flag --out removed",
    "CLI flag --output added"
  ]
}

Outcome

Illustrative
Likely breaking

Probability of yes is above your upper threshold.

Why

Scripts using --out will break.

Using it well

  • Extract public surface changes with tools (API diff, schema diff) and pass them in; the model judges impact, not the diff itself.
  • Fixing a bug that users relied on can be breaking. Those often land in the unclear band, which is right.

Request definition

POST https://api.typesafe.ai/v1/systemone
{
  "model": "jev-latest",
  "state": {
    "description": "<description>",
    "public_surface_changes": "<public_surface_changes>"
  },
  "questions": {
    "breaking_change": {
      "type": "noul",
      "instructions": "Does this change alter public behaviour in a way that could break existing users?",
      "criteria": {
        "true": "Removes or renames public APIs, flags or config, changes defaults, or changes output formats users rely on.",
        "false": "Adds new behaviour, fixes bugs without changing contracts, or only changes internals."
      }
    }
  }
}

Request shape from the System One API reference; a Kev server accepts the same body. Replace the placeholder state with your data. Requests need your own API key or server.

Version History

v1Current Versionabout 8 hours ago@f

Initial version

Comments (0)