Risk Score

Every AI-generated PR needs
more than a thumbs-up.

It needs a clear view of merge risk. Code-quality and historical signals come together in one explainable assessment: the score, the risk factors, and the evidence.

Book a demo Explore use cases
Your PR's risk, with the evidence attached.
GitHubHandle partial refundsbilling-api / PR #412 / @dana
Last 21 days
Risk Score
46/ 100
Medium risk
PR risk assessment

Medium risk

Recent bugs, missing-test findings, and increasing rework contribute to this PR's risk.

Risk assessment based on the available evidence.

Contributing risk factors

  1. Code-quality concerns in this change.

    Slop Score: 41 / 100. Three missing-test findings and two duplicated blocks.

  2. The changed file has recent bugs.

    src/billing/refund.py had two bugs in 21 days; one is still open.

  3. Recent rework is increasing.

    22% of recently added code in this file was rewritten, compared with 11% across the repository.

Inspect the evidence
Illustrative weekly evidence, oldest to newest
Signal Week 1 Week 2 Week 3
Author's PR Slop Scores 22 30 41
Open bugs in changed file 0 1 1
Recent code already rewritten 4% 9% 22%

Three questions.
One better-informed decision.

What raises concern?
A score and risk band summarize the measured signals. The ranked concerns name what deserves attention.
What is the evidence?
Current PR findings, affected files, mapped bugs, ownership, and weekly history make the reasoning inspectable.
What remains unknown?
Missing inputs are shown explicitly. An unmeasured signal is not evidence of low risk.

Four ways to see
the risk before you merge.

Connect the current change to recent quality, bugs, and rework. Understand which signals contribute to a PR's risk, and why.

Identify high-risk PRs.

See the combined risk of a change, rather than judging it by the diff alone. Bring code quality, ownership, and recent PR history into one assessment.

  • Current changeSlop Score & changed files
  • Author contextOwnership & recent PRs
  • Risk assessmentScore, level & evidence
See a PR risk assessment

Detect risk in bug-prone code.

A small change can touch a fragile part of the codebase. Surface recent defects and unresolved bugs in the affected files to put that change in context.

  • Affected filesMapped bug history
  • Unresolved defectsOpen issues
  • Recent historyWeekly bug trends
Explore bug-history signals

Spot risk from repeated rework.

Understand when a PR touches code that keeps changing. Recent rewrites and PR setbacks can reveal instability that a clean-looking diff does not show.

  • Code churnRecently added code rewritten
  • PR setbacksReverts & unmerged changes
  • Trend windowLast 21 days by default
See how history informs risk

Assess risk in AI-generated code.

More generated code is not proof of quality. Combine the PR's Slop Score with historical defect and rework signals to understand the risk of merging it.

  • Code qualityDuplication & nonexistent APIs
  • Test evidenceMissing tests & coverage
  • Historical contextRecent bugs & rework
See how signals come together

Approval is a click.
Understanding takes context.

A clean-looking diff is only part of the story. Risk Score looks at the change, the people familiar with the code, and what has happened there recently.

Incoming pull request Diff + changed files + metadata

Who

Author & ownership

Recent PR quality, rework, setbacks, and authorship of the changed code.

What

The code being changed

Slop Score, changed files, ownership, and test evidence for this commit.

History

Recent bugs & rework

Mapped bugs, unresolved issues, and weekly trends in the affected files.

Risk ScoreScore + risk level + evidence
Contributing signals Supporting evidence

The assessment shows the risk associated with a PR. Team-level risk and production incident history are part of the proposed extended assessment.

Not just a number.
A reason to look closer.

Slop Score describes the quality of a change. Risk Score puts that change in context. Every concern should lead back to evidence, not a black-box verdict.

Recent quality, not a permanent label.

An author's PR history, week by week.

Increasing code-quality concerns
Quality of this PR
Duplication, missing tests, nonexistent APIs, and other Slop Score findings on the current commit.
Bugs in the affected code
GitHub issues and connected Jira bugs mapped to the files being changed, including unresolved bugs.
Rework and setbacks
Recently added code rewritten soon after landing, plus author PR reverts and closed-unmerged changes.
Coverage and confidence
Coverage when measured on this commit. Missing inputs are called out, never silently treated as zero risk.

A useful summary.
Not a guarantee.

Think of a credit score's role as a summary of historical signals, not a guarantee about the next decision. Risk Score brings that idea to a pull request, with the underlying concerns made visible.

It is not a credit model or a developer rating. It reports a score out of 100 and a Low, Medium, or High band when enough evidence exists. Individual findings remain visible even when the overall score is low.

The next PR shouldn't
start from zero.

Stability comes from closing the loop: assess a change, preserve the evidence, then bring what happened back into the history of the codebase.

  1. 1

    Assess the change

    Combine current Slop Score with recent bugs, ownership, and rework.

  2. 2

    Explain the risk

    Show the contributing signals and the evidence behind the score.

  3. 3

    Keep the evidence

    Posted risk cards preserve Slop Score and coverage for later assessments.

  4. 4

    Use newer history

    Mapped bugs, rework, and PR setbacks inform the next assessment.

New evidence informs the next PR. Each assessment reflects the latest history.

The full picture
of change risk.

From evidence about today's PR to the broader engineering-risk workflow, spanning the change, its history, and the assessment.

Current PR quality

Reuse Slop Score evidence for the current commit, or run it when that evidence is missing.

Changed files & ownership

Identify whose code is changing and the authors of the lines the PR rewrites.

Test coverage

Include coverage from a CloudAEye checklist on this commit. Report unmeasured coverage explicitly.

Product-area detection

Map files and symbols to components and product areas using paths, code structure, and history.

Weighted change footprint

Show how much of a change touches each area, with mapping confidence and PR complexity.

Review-process signals

Add unreviewed merges and review-duration history to the wider assessment of review practices.

Start with the PR
you're about to merge.

With CloudAEye Code Review configured, request a risk assessment in the PR conversation.

@cloudaeye /risk_score

In Claude Code: /cloudaeye:risk-score #412

Read the Risk Score guide

Evidence in the conversation.
Not another dashboard.

The PR command posts a Change Risk Card alongside the change. The Claude Code command asks before posting; saving the card builds history for later assessments.

The score summarizes risk; the supporting evidence explains it.

Know the risk.
Then decide.

Understand the risk associated with every pull request.

Book a demo