Sigma user documentation

Sigma reviews pull requests on GitHub. A pull request is the place to read and discuss its findings; the Sigma workspace holds repository settings and more detailed run history. One GitHub App, Sigma Mnemoverse, posts the reviews.

What Sigma is

• It reviews a snapshot of the pull request's exact head and base commits.
• A producer proposes findings. A fresh verifier checks the candidates; only confirmed findings count as verified.
• Each configured reviewer has its own version, execution path, schedule, findings and history. Several reviewers can review the same PR state.
• Reviews are posted to GitHub with up to five inline findings per review and a neutral progress check. Rules can add a separate aggregate verdict when its requirements pass.

What Sigma is not

• Sigma never merges pull requests or edits your code. Its write permissions allow reviews and checks, not implementation commits.
• A neutral progress check is not an approval. Repository administrators control branch protection; Sigma does not configure merge gates for you.
• A reviewer being configured does not prove its executor is ready, that its credentials belong to the person viewing the page, or that a usage estimate is a bill. Execution and costs stay separate.
• Sigma does not yet offer an open, multi-account reviewer service. This pilot's Sigma sign-in is invite-only for its owner. Signing into Mnemoverse, granting GitHub access and authorizing a model provider are different connections.

Who this documentation is for

A developer can read a review and reply on GitHub. A maintainer chooses repositories and reviewer modes on Sigma's /connect page and can inspect runs. Running an instance, credentials, isolation policy and budget administration belong in the operator runbooks.

How to read this documentation

This draft is checked against Sigma source 44e7a28 on 1 October 2026. It is not a deployment receipt. A specific installation may have older reviewers, different enabled executors, or Comments without Rules. Use the identity and recorded status on the actual run; a setting or source implementation alone does not establish live availability. Historical reviews keep the wording and version with which they were published.

Pages

1. What Sigma does with your code — snapshots, execution boundaries, provider calls, retention and the secret guard.
2. Reviewers and executors — versions, stages, three execution paths, costs and provider constraints.
3. Modes and requests — Automatic, On request, Off, explicit requests, permissions and drafts.
4. Reading a review — status, findings, verification, aggregate verdicts and costs.
5. Replies and rechecks — deferral and targeted work.
6. Limits and budget — holds, waiting and recovery.
7. Glossary — terms used throughout Sigma.
8. UI hint text — the short in-product dictionary and its stable documentation anchors.