A finding only counts when its evidence holds up.
PRism checks large and AI-generated pull requests against their stated intent, cross-file dependencies, and test coverage. A deterministic gate checks each citation; anything it cannot support remains clearly marked as unverified.
DIFF FACTS → FOUR REVIEW FACETS → CITATION CHECK
The review pipeline
01
Connect GitHub
You sign in through the PRism GitHub App and install it on the repositories you want analyzed. Repository access uses short-lived, read-only installation tokens (metadata, contents, and pull requests only).
02
Ingest the exact PR
Submit a pull request URL. PRism fetches the PR's exact unified diff and head/base commit SHAs from GitHub, and stores the diff as a private artifact served only to you through the API.
03
Compute deterministic facts
Before any model runs, the facts engine extracts exact changed-line ranges, walks Python imports to build cross-file dependency edges, and loads CI coverage that matches the PR's exact head SHA.
04
Run four review facets
Intent vs spec, cross-file impact, test-coverage gaps, and risk hazards run concurrently. Each facet sees only the facts, description, and diff context it needs, and returns strictly typed, structured findings.
05
Verify every citation
The deterministic evidence gate checks each finding's citations against the computed facts. Unsupported claims are demoted to an unverified appendix with the reason — they are never shown as verified.
06
Read the brief
You get a risk-ordered brief with verified findings, exact file and line citations linked into the diff, coverage provenance, and the verification state of every claim.
What verification means
Verified findings
The gate confirmed every citation against the facts: the cited line exists and is changed by this PR, the import edge exists, or the coverage report covers (or does not cover) the cited line.
Unverified appendix
Claims that could not be tied to facts. They remain readable, with the exact rejection reason per citation, so you can judge them yourself.
How coverage provenance works
Coverage is never guessed. Your CI uploads a coverage.py report to PRism's intake endpoint using a GitHub Actions OIDC identity, bound to the exact commit it was produced for. Each analysis records which report — if any — it used:
Coverage accepted
A CI coverage report was uploaded for this exact commit, passed integrity checks, and parsed cleanly. Coverage claims can cite it.
Coverage rejected
A report was uploaded but failed the SHA match or parse. Coverage is treated as unknown and cannot back a coverage-gap claim.
No coverage artifact
Nothing was supplied for this commit. Test-coverage claims are limited to what the diff itself shows, and the report's provenance says so.
Scope and limits
- —Analysis runs entirely on the PRism backend. PRism never runs your PR's code, and it never posts comments back to GitHub.
- —Facts are deterministic; models only propose findings, and the gate decides what you see as verified.
- —Benchmark comparisons appear only once the backend publishes measured results from the seeded corpus — no numbers are invented for display.