How Aevral reviews a pull request
What the review reads, what it never reads, and what has to be true before it is allowed to say anything. The long version, with the grounding rules and a worked finding, lives on the documentation site.
One review, five phases
- 1Read
- The diff of every changed file, plus the full file at the head commit for security-critical changes such as auth, identity, input handling, SQL, and routing. Never git history. Never whole-repo retrieval for a review. Never executed code.
- 2Pack
- Most security-relevant first, into bounded model calls. Generated files, lockfiles, translation and fixture data are skipped by rule and named; secret-looking paths are never sent. On a large pull request the Check states exactly what was covered.
- 3Review
- Three specialist passes read the same packed content: authorization, IDOR, and business logic; injection classes; identity and AI-integration boundaries. A finding must name the attacker, the input they control, the path to the sink, the missing control, and the consequence.
- 4Ground
- The cited code must match, verbatim and uniquely, lines the pull request actually added (or, for a deleted check, removed). An ungrounded finding is discarded mechanically, not by judgment. Pre-existing code beside a touched line can never publish.
- 5Post
- Only a diff-proven verdict publishes, at most five findings, pinned to added lines as advisory comments. Unproven leads are listed as unverified in the Check, never posted. Silence on a clean pull request is the expected outcome.
The limits, as numbers
Every reviewable file ends a run with a disclosed fate: read, truncated, not read with a reason, excluded by rule, or withheld as sensitive. A partial review never reads as a clean bill of health.
| Limit | Value |
|---|---|
| Not reviewed at all (neutral Check) | 600 changed files, or 3,000,000 diff characters |
| Model context per review | Up to 8 batches of 80,000 characters (default 4, by plan) |
| Full file content | Up to 40 security-critical files, 40,000 characters each |
| Published findings | 5 per review, most severe first, the cut disclosed |
| Unverified items listed | 5, never as comments |
| Grounding window | 1 to 6 consecutive added or removed lines, within 10 lines of the citation |
It is probabilistic, not exhaustive. Misses happen and are published: the receipts page shows the planted-vulnerability runs, including the ones the review did not catch. Receipts
Common questions
- Does it read the full files or just the diff?
- Both, in a defined order: the diff of every changed file first, then the full file at the head commit for changed files whose paths look security-critical (up to 40 files, 40,000 characters each). It never reads git history and never executes code.
- What is a grounded finding?
- One whose cited snippet matches, verbatim and uniquely, lines the pull request actually added, within 10 lines of the citation. Grounding is checked mechanically against the diff; a paraphrased or misplaced quote discards the finding.
- Why is a review silent when clean?
- Because silence is the honest outcome for most pull requests, and a bot that comments on everything trains readers to ignore it. A clean review posts one advisory Check; a new review notification only goes out for new findings at medium severity or above, inline comments only at high or above.
The long version
The documentation site carries the full pipeline: the packing rules, the three passes and their class lists, the grounding gate in detail, verdicts and the unverified tier, and a worked finding from the planted-vulnerability corpus.