diff --git a/.github/PULL_REQUEST_TEMPLATE/general.md b/.github/PULL_REQUEST_TEMPLATE/general.md
index 4f1a18e925e..7c264697de5 100644
--- a/.github/PULL_REQUEST_TEMPLATE/general.md
+++ b/.github/PULL_REQUEST_TEMPLATE/general.md
@@ -147,10 +147,12 @@ If you're seeing a delay in your PR being merged, ping the LiteLLM Team on [Slac
      short bullet points inside each, just like the TLDR: one line per bullet, roughly 10 words max
      Call out known limitations, follow-up work, or anything a reviewer should watch out for
      Include only the tiers that have caveats; drop the empty ones
-     - Severe: inherent to what the PR deliberately ships, there even when the code works as intended:
-       it can degrade or take down a running deployment (e.g. a slow or table-locking boot migration),
-       rewrite data by design, break an existing workflow on purpose, or change auth behavior. An
-       operator must plan around it before rollout
+     - Severe: an evidenced rollout hazard inherent to the intended change, requiring operator planning,
+       such as downtime, destructive data changes or a supported workflow requiring migration.
+       A changed value or auth implementation alone is not such a hazard. For compatibility breaks,
+       name the previously valid request/config, before/after behavior and required migration.
+       Provider price refreshes and fixes restoring intended behavior are not breaking by themselves.
+       Keep billing and security risks assessed separately (2026-11-03, price correction false positive)
      - High: an unintended hole: a correctness, security, data-loss, or backward-compatibility bug,
        unsafe to ship as is
      - Medium: a real gap someone can hit, but with a workaround or a narrow blast radius
diff --git a/AGENTS.md b/AGENTS.md
index 9aa9ab32528..29b66dbf2e8 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -115,7 +115,7 @@ Follow these coding conventions for new/updated code (a three-line fix in a lega
 - API-fragmentation-aware: when logic must branch on which API surface produced or consumes data (e.g. chat completions vs Anthropic Messages vs Responses API shapes), proactively look for an existing shared helper (e.g. `litellm_core_utils/prompt_templates/factory.py`) before writing per-surface parsing in the new module. If none exists, add one there instead of duplicating the same format-detection logic in every new guardrail/integration
 - Current default for new model names: logic that picks behavior from a model-name table (tokenizer, message framing, supported params) gives a provider's model the table does not list yet that provider's current behavior, never its oldest, since providers ship names faster than any table is updated
 
-Follow conventional commits for commit names and PR titles
+Follow conventional commits for commit names and PR titles. Reserve `!` and `BREAKING CHANGE` for an evidenced incompatibility with a supported public contract. Name the previously valid request, config or integration, its before/after behavior and the required caller or operator migration. Observable differences alone, including provider price refreshes, additive changes that preserve existing contracts, internal refactors and fixes restoring intended behavior, do not qualify. Investigate uncertain compatibility risks without asserting a confirmed break. Keep billing, security and rollout risk assessments separate (2026-11-03, a price correction was mislabeled breaking)
 
 ## Think Before Coding