Review the Release Case, Not Just the Code

The implementation review passed. The evaluation report looks good. The rollback plan is a sentence saying “revert if needed.”

That last sentence may be the most important unfinished part of the release.

/carbon-release-review synthesizes the release evidence from a separate review perspective: code, evaluations, risks, production signals, severe failures, monitoring, rollback, and evaluator independence.

Look for contradictions between artifacts

The model report may claim broad improvement while a small high-risk slice regressed. The deployment plan may expand exposure beyond the population tested. The rollback procedure may restore code without reversing a data migration.

Each artifact can appear reasonable in isolation. The release case depends on their agreement.

The review should identify which conclusion is supported, which condition is assumed, and which gap could materially change the recommendation. It should not treat a confident author as another source of evidence.

Give it the actual release boundary

/carbon-release-review challenge the proposed rollout using the current diff, eval results, incident history, and rollback plan

The output is a scoped recommendation and its supporting rationale, not permission to deploy or roll back. If necessary evidence is unavailable, the limitation belongs in the conclusion.

This is useful before a consequential launch because the unanswered question is often between teams or documents rather than inside a single function.

A release deserves more than several individually persuasive reports. It needs a coherent account of what will happen, how you will know, and what you can do if you are wrong.

Install CARBON at testers.ai/carbon for a supported coding agent such as Claude, Codex, or Cursor.

— Jason Arbon, CEO testers.ai