Documentation

Review evidence

Preview deployments, scans, coverage and test results attached to the pull request they describe.

Review evidence is proof of verification attached to the pull request it belongs to: a preview you can open, a scan result, a coverage delta, a recorded browser run.

The principle is simple — evidence and the code it describes should arrive together. A scan result in a separate dashboard nobody opens is not evidence, it is homework.

What can be attached

Coroid integrates with providers across several classes:

ClassProviders
Git-nativeGitHub Actions environments, GitLab Review Apps
Static hostingVercel, Netlify, Cloudflare Pages, AWS Amplify
Full-stack previewsRender, Railway, Heroku Review Apps, Fly.io, Northflank, Qovery, Porter
Mobile distributionExpo EAS, TestFlight, Google Play internal testing
Review and scanningCodeRabbit, Qodo / PR-Agent, Greptile, Cursor Bugbot, SonarQube Cloud, Snyk, Semgrep
Coverage and visualCodecov, Chromatic, Percy
End-to-end and monitoringCypress Cloud, Checkly, Maestro, BrowserStack
CustomCustom evidence webhook

Thirty-one providers in total. The custom evidence webhook covers anything not on the list.

Each provider declares which evidence types it can produce — web preview, mobile build, AI review, security scan, coverage, visual review, end-to-end and performance — and how Coroid ingests it, whether from the git surface, from CI output, or by calling the provider's API directly.

You probably already have most of this

That is the point. Teams adopting Coroid usually have preview deployments, a scanner and coverage reporting already. Review evidence connects what exists rather than replacing it.

Configure providers under the organization's connection settings; evidence then attaches automatically to pull requests Coroid opens.

Evidence and gates

Evidence and gates are related but distinct:

  • Evidence is information attached for a human to consider.
  • A gate is a decision the system enforces.

Evidence can feed a gate — a coverage threshold gate reads the coverage evidence — but most evidence is just information. Not everything worth seeing is worth blocking on.

Choosing what to attach

More evidence is not better. Each item competes for reviewer attention, and a pull request carrying fifteen artifacts gets the same glance as one carrying three.

Attach what changes a decision:

  • a preview whenever a change is user-visible
  • coverage when the delta matters
  • security scanning on anything touching input handling, auth or dependencies
  • visual diffs on design-system and component work