How a review actually works

The whole path, in order, with nothing left out. If you are evaluating Garboard, this is the page that tells you whether the determinism claim is real or marketing.

The path

pull_request (opened | synchronize)
        │
        ▼
  verify webhook signature
        │
        ▼
  fetch CHANGED FILES ONLY, at the head SHA
        │
        ▼
  load the latest RCD for this repo   ← conventions derived by an earlier scan
        │
        ▼
  ┌─────────────────────────────────────────────┐
  │  conventions.Check   — your repo's own rules │
  │  secops.Check        — built-in security     │
  │  adopted catalog rules                       │
  │  custom WASM rules                           │
  └─────────────────────────────────────────────┘
        │
        ▼
  rank: severity, then confidence
        │
        ▼
  drop every finding with no file:line evidence
        │
        ▼
  take the top 3
        │
        ▼
  compose one comment  ──►  UPSERT (edit in place on later pushes)

Why each step is the way it is

Changed files only, at the head SHA. Not the whole repo. A review is about this change, and reviewing files the author did not touch produces findings they cannot act on. The head SHA matters because a review that reads main describes a state nobody proposed.

The RCD is loaded, not derived. Conventions come from a separate scan of the whole repository. Deriving them from a diff would mean the conventions changed every time someone opened a pull request, and a convention that moves is not a convention.

Rank by severity, then confidence. Confidence second, deliberately: a critical finding we are less sure about still outranks an advisory we are certain of.

No evidence, no finding. A finding without a file and a line is dropped by the ranker. Not shown with a caveat — dropped. A reviewer who cannot go look is being asked to take our word for it, and that is the thing this product is supposed to replace.

Top three, and one comment. Not because three is magic, but because a review that lists twenty things gets skimmed and then muted. The comment is upserted — edited in place — so a pull request with six pushes has one comment, not six.

The time budget

Webhook to comment is budgeted at p95 under 60 seconds, and that budget is a test rather than an aspiration. Scanning is budgeted separately at under two minutes per 500 resources.

What runs where

Nothing in this path talks to your cloud. The gate reads files fetched through the git host’s API and nothing else. There is no credential in Garboard that could call AWS, and no code path that runs apply.