CARF — Rollback Thresholds Shouldn't Be One-Size-Fits-All

Most rollback automation treats every change the same. One health-check threshold, one rollback trigger, whether you shipped a copy tweak or migrated the database layer. A 2% error rate spike after a CSS change and a 2% error rate spike after an infra migration get the same response — or worse, the same lack of response.

That's the wrong default. Different changes carry different blast radii. Rollback sensitivity should scale with change type, not sit at a single global setting.

The Hypothesis

CARF — Change-Aware Rollback Framework — starts from a simple claim: if you know what changed, you can set how sensitive the rollback decision should be. A dependency bump warrants tighter thresholds than a comment edit. An infra migration warrants the tightest.

The simulator below lets you adjust per-change-type thresholds and see how the decision engine responds to a simulated canary deploy.

Two-Tier Classification

Tier 1 uses fast manifest-level heuristics — what files changed, whether it's code, config, a dependency lockfile, or infrastructure manifests. Cheap and fast enough to run on every deploy.

Tier 2 kicks in when Tier 1 isn't conclusive. Tree-sitter AST diffing scores actual code complexity — how many functions changed, how deep the edit goes. Tree-sitter over Babel for language agnosticism: one parser interface across TypeScript, Python, Go, and more.

Four-Phase Architecture

1. Change Classifier — Tier 1 + Tier 2 analysis, outputs change type and complexity score
2. Metrics Collector — pulls canary telemetry from Prometheus/Grafana during the deploy window
3. Decision Engine — compares live metrics against per-change-type thresholds
4. Rollback Executor — triggers kubectl rollout undo or git revert based on the decision

Research, Then Implementation

The framework started as a research paper — co-authored, peer-reviewed, arguing the case for change-aware rollback thresholds with empirical data from canary deployments. The paper established the hypothesis; the implementation is now proving it in production-like environments.

Scaffolding for core-api/ is underway, starting with the Change Classifier module.

Where It Is Now

Architecture is finalized. Active R&D on the Tier 2 classifier. Implementation of the core API and decision engine is underway — not production-ready yet, but past the whiteboard stage.

The goal is a rollback system that asks "what changed?" before it asks "should we roll back?"