Review
Review is Cendriix’s AI-powered code review surface. It analyzes every pull request across your connected repositories — GitHub, GitLab, Bitbucket, and Azure DevOps — to surface bugs, security vulnerabilities, and code quality issues with file-and-line precision. Each finding comes with an explanation and a suggested fix you can apply in one click. Access via Operate → Review in the sidebar.
How it works
Review watches the repositories you’ve connected. When you click Sync, it discovers new pull requests across all your SCM providers, creates a review record for each one, and queues them for AI analysis. The analysis pipeline runs five steps for every PR:
- Initialize review — creates the review record and marks it as running.
- Fetch PR diff — retrieves the unified diff directly from your SCM provider’s API (GitHub, GitLab, Bitbucket, or Azure DevOps).
- Analyze code changes — sends the diff plus relevant Cortex context to an AI model (Amazon Bedrock) that reviews the code for bugs, vulnerabilities, performance issues, and style problems.
- Run security scan — a focused pass over the diff looking for SAST findings: unsafe patterns, deprecated APIs, hardcoded secrets, and known CVEs in dependency changes.
- Generate findings — parses the model output into structured findings with severities, categories, file paths, line numbers, and suggested fixes, then completes the review with a verdict and risk score.
Each step’s status is tracked in real time. If any step fails, it’s marked accordingly and you can retry.
Multi-SCM support
Review works identically across all four supported source control providers:
| Provider | Auth method | What Review accesses |
|---|---|---|
| GitHub | GitHub App installation tokens | PR diffs, commit files, PR comments, CI check runs |
| Bitbucket | OAuth / App Password via Marketplace token resolver | PR diffs, PR comments, build statuses |
| GitLab | OAuth via Marketplace token resolver | Merge request diffs, MR notes, pipeline statuses |
| Azure DevOps | PAT / Entra ID OAuth via Marketplace token resolver | Pull request diffs, PR threads, build statuses |
The provider is detected automatically from the PR URL. No extra configuration is needed once the repository connection is set up in Connectors.
The dashboard
The Review landing page shows two views: Repos and All Reviews.
Repos tab
Groups your pull requests by repository. Each row shows:
- Repository name (e.g.
cendriix-ai/cendriixai-app) - PR count — total pull requests in the current time window
- Avg Risk — average risk score across all reviewed PRs in that repo
- Merge status breakdown — how many are open, merged, or closed
- Health indicator — a colored dot: green (healthy), amber (warning), or red (critical)
Expand a repo to see its individual PRs with verdict badges, risk scores, finding counts, and relative timestamps.
All Reviews tab
A flat list of every PR across all repositories. Supports:
- Search — filter by repo name, PR title, or author
- Verdict filter — Approved, Changes Requested, Blocked, Pending
- Merge status filter — Open, Merged, Closed
- Sort — by risk score, date, or finding count
Summary cards
At the top of the dashboard, five cards summarize the current state:
| Card | Meaning |
|---|---|
| Repos Reviewed | Number of repos with at least one reviewed PR |
| Avg Risk | Average risk score across all PRs |
| Healthy | Repos where the latest review is Approved and avg risk is low |
| Warning | Repos with high-severity open findings or Changes Requested verdict |
| Critical | Repos with critical open findings, a Blocked verdict, or avg risk above 50 |
Time-window behavior
The dashboard shows a rolling three-day window by default:
- Open pull requests are always shown regardless of when they were created. An open PR from two weeks ago still appears.
- Merged and closed pull requests are shown only if they were created within the last three days. This prevents the dashboard from filling up with old, already-handled PRs.
Risk score
The risk score is a number from 0 to 100 that represents the overall risk level of a pull request. It is computed by the AI model during analysis based on the severity and quantity of findings.
How it’s calculated
The risk score is determined by the AI code reviewer during the analysis step. The model evaluates the PR diff and assigns a score based on these guidelines:
| Range | Meaning | Typical triggers |
|---|---|---|
| 0 — 20 | Clean | No issues found, or only trivial info-level notes |
| 21 — 40 | Low | Minor style or info-level findings only |
| 41 — 60 | Medium | Some medium-severity findings that deserve attention |
| 61 — 80 | High | High-severity issues are present — bugs, security, or performance |
| 81 — 100 | Critical | Critical vulnerabilities or blocking issues found |
The model considers:
- Finding severity distribution — the presence of critical or high-severity findings pushes the score higher.
- Finding category mix — security and correctness issues weigh more than style.
- Quantity — more findings generally increase the score.
- Impact scope — issues affecting auth, data handling, or public APIs score higher than internal utilities.
The score is clamped to the 0—100 range and rounded to an integer. If the AI response cannot be parsed, the score defaults to 50 (medium).
Repo-level average
Each repository’s Avg Risk is the arithmetic mean of all individual PR risk scores in that repo (within the time window). This drives the dashboard summary cards and the repo health indicator.
Health status
Every repository gets a health status based on the combination of open findings, the latest verdict, and average risk.
| Status | Criteria |
|---|---|
| Healthy (green) | No high/critical open findings, latest verdict is not Blocked or Changes Requested, avg risk at or below 20 |
| Warning (amber) | Any high-severity open finding, latest verdict is Changes Requested, or avg risk between 21 and 50 |
| Critical (red) | Any critical-severity open finding, latest verdict is Blocked, or avg risk above 50 |
Verdicts
The verdict is the top-level assessment of a pull request.
| Verdict | When it’s assigned |
|---|---|
| Approved | No significant issues found. Low and info findings are acceptable. |
| Changes Requested | Medium or higher findings exist that should be addressed before merging. |
| Blocked | At least one critical or high-severity security or correctness finding exists. |
| Pending | Analysis has not started or is still running. |
| Error | Analysis failed or could not complete (e.g., diff fetch failure, model unavailable). |
Findings
A finding is a single issue identified in the PR diff. Each finding has:
| Field | Description |
|---|---|
| Severity | critical, high, medium, low, or info |
| Category | security, correctness, performance, style, or sast |
| Title | A short summary (e.g., “SQL injection via string concatenation”) |
| Description | A detailed explanation of why this is an issue |
| File path | The exact file where the issue was found |
| Line number | The line in the diff where the issue starts |
| Suggestion | A suggested code change to fix the issue |
| Status | open, resolved, dismissed, or false_positive |
Bugs vs. Flags
The findings list is split into two groups:
- Bugs — high-priority items: critical/high severity, or security/correctness category. These are real issues that should be fixed.
- Flags — everything else worth a look: medium/low/info severity style, performance, or SAST findings.
Reviewing a pull request
Click on any PR to open a three-pane workspace:
Left pane — Findings list
All findings for this PR, split into Bugs and Flags tabs. Supports:
- Severity filter — show only critical, high, medium, etc.
- Category filter — security, correctness, performance, style, sast
- Keyboard shortcuts —
j/kto navigate up/down,Escto deselect
Center pane
Switch between three views:
| View | Content |
|---|---|
| Analysis | The five analysis steps with real-time status indicators (running, completed, failed) |
| Diff | The full unified diff with a file tree sidebar, line counts, and findings highlighted inline |
| Finding | A single finding in detail: severity badge, category, file and line, explanation, and suggested code change |
Right pane — Details
- PR metadata — title, author, branch, head SHA, merge status
- CI checks — status of each check run (GitHub Actions, Bitbucket Pipelines, GitLab CI)
- Self-review verdict — the AI’s overall assessment badge
- Merge readiness — a self-review panel summarizing whether the PR is ready to merge
- Chat — a built-in AI chat to ask follow-up questions about the review (uses the review context + Cortex knowledge)
Acting on findings
Resolve, dismiss, or reopen
Change the status of any finding. Mark it resolved when fixed, dismiss it as a false positive, or reopen it if you change your mind.
Post a comment
Send a pre-formatted review comment directly to the PR on your SCM (GitHub, GitLab, or Bitbucket). Azure DevOps comment posting is not yet supported. The comment includes the severity, file location, description, and suggested fix.
Apply Fix (auto-fix)
For any finding with a suggested code change, click Apply to commit the fix straight to the PR branch. Review:
- Reads the current file content from the PR’s head branch
- Applies the suggested change
- Commits and pushes to the PR branch with a descriptive commit message
- Updates the finding status to Resolved
This works on the following SCMs:
- GitHub — uses the Contents API to read and commit
- GitLab — uses the Commits API to create a commit
- Bitbucket — uses the Source API to push a commit
Azure DevOps auto-fix is not yet supported.
After applying, a notification comment is automatically posted on the PR with details of what was fixed.
Fix with Cendra
For more complex fixes that need broader context, click Fix with Cendra. This opens a Cendra chat session pre-loaded with the PR context and finding details. Cendra can then make multi-file changes, run tests, and open a follow-up PR.
Export
Download the full review as a Markdown report. The report includes the verdict, risk score, all findings with descriptions and suggestions, and the PR metadata.
Sync
The Sync button on the dashboard triggers a full pull request discovery cycle:
- Queries each connected SCM for the latest pull requests across all repositories
- Creates review records for any PRs not yet tracked
- Updates merge status for existing reviews (marks merged/closed PRs accordingly)
- Queues pending and previously failed reviews for AI analysis
Sync is also triggered automatically on a polling interval while the Review page is open (every five minutes).
Merge status refresh
Review keeps merge status up to date in two ways:
- Bulk sync — during Sync, all open reviews are checked against the SCM for merge/close events
- Lazy refresh — when you open a specific review that hasn’t been synced in the last hour, a background check updates its merge status
Cortex integration
When analyzing a PR, Review queries Cortex for relevant knowledge atoms — documentation, architecture notes, dependency context — and includes them in the analysis prompt. This gives the AI reviewer deeper understanding of your codebase, so findings are more accurate and suggestions are more relevant.
If a PR modifies dependency files (package.json, Cargo.toml, pyproject.toml, go.mod, requirements.txt), the dependency changes are noted separately in the analysis context.
Keyboard shortcuts
| Key | Action |
|---|---|
j | Next finding |
k | Previous finding |
d | Toggle diff view |
Esc | Deselect / close |
API reference
Review exposes a RESTful API at /v1/reviews. All endpoints require authentication and are scoped to the current tenant.
| Method | Endpoint | Description |
|---|---|---|
GET | /reviews | List reviews with filtering and pagination |
GET | /reviews/summary | Dashboard summary (total reviews, avg risk, verdict distribution) |
GET | /reviews/repos | Per-repository health stats |
GET | /reviews/metrics | Time-series metrics for charts |
GET | /reviews/:id | Get a single review with all findings |
GET | /reviews/pr/:owner/:repo/:prNumber | Look up review by PR |
POST | /reviews | Create a new review |
POST | /reviews/:id/complete | Complete a review with verdict and findings |
POST | /reviews/:id/fail | Mark a review as failed |
POST | /reviews/:id/analyze | Trigger AI analysis on a PR |
PATCH | /reviews/findings/:id/status | Update finding status (resolve, dismiss, reopen) |
POST | /reviews/:id/comment | Post a comment to the PR |
POST | /reviews/:id/autofix | Apply an auto-fix for a finding |
POST | /reviews/:id/chat | Chat about the review |
POST | /reviews/sync | Trigger PR discovery and sync |
Query parameters
The list endpoints accept optional from and to parameters (ISO 8601 datetime) to control the time window. The default frontend behavior sends from as three days ago.
Filtering
| Parameter | Type | Description |
|---|---|---|
repo | string | Filter by repository name |
verdict | enum | approved, changes_requested, blocked, pending, error |
merge_status | enum | open, merged, closed |
risk_min | number | Minimum risk score (0—100) |
risk_max | number | Maximum risk score (0—100) |
from | datetime | Start of time window |
to | datetime | End of time window |
page | number | Page number (default 1) |
limit | number | Results per page (1—100, default 20) |
Webhook integration
Review supports inbound webhooks from CI/CD systems. When a GitHub Actions, GitLab CI, Bitbucket Pipelines, or Azure DevOps Pipelines run completes, a webhook can notify Review to trigger analysis on the associated PR. Configure webhooks in Settings → Integrations.
See also: Cockpit, Cendra, Cortex, Connectors, Policies & Guardrails