Every review follows the same pipeline. Understanding it makes the rest of the product obvious.

1. The webhook arrives

Your provider posts the event. GitHub and GitLab payloads are cryptographically verified against the integration's signing secret. The pull request is recorded whether or not it ends up being reviewed.

2. Gates run before any spend

Two checks happen before a job is created: the author allowlist, and your plan's monthly review quota. If the quota is exhausted the PR is still tracked, the review is skipped, and the webhook still returns success so your provider never retry-storms.

3. Jobs are queued

Work is a database-backed queue. Opening a PR enqueues a pipeline of three jobs — describe, review, improve. Workers claim jobs atomically (SELECT … FOR UPDATE SKIP LOCKED), so multiple workers never take the same job. A job whose worker dies is automatically requeued.

4. The engine runs

Each job runs pinned to your tenant's configuration: your chosen AI model, your provider token, and your custom instructions. The engine reads the diff and the surrounding files, then runs the model.

5. Analyzers run alongside

On review jobs, eight deterministic analyzers scan the same diff — see Security analyzers. Their findings are merged with the AI's.

6. The result is published

ReviewIQ posts one persistent comment, edited in place on later commits rather than spamming new ones. Security findings go inline on the exact line; if a line can't be resolved the finding falls back to a file-level comment so it is never silently lost. Strong suggestions are also posted as committable blocks, and a verdict is set if the repo allows it.