Reviewers and executors

Lineages and versions

Bravo and Charlie are sibling reviewer constructions, not quality rankings or release stages. Each has its own versions. A version identifies the workflow's prompts, schema and attempts; using a different executor does not make a new version. Historical Alpha/Beta names and older versions keep their original identity.

Read the version on the repository's configured reviewer or the individual run. A newer construction in source does not change an existing repository or establish that the same version is available in your installation.

Stages: producer and verifier

The producer reads the change and proposes candidates, recorded as suspicions. A verifier, in a fresh context, checks those candidates and can confirm, reject or reclassify them. Only confirmed candidates are verified findings. A reviewer does not receive sibling reviewers' findings while working.

Executors

An executor records how the stages run. It does not establish who owns a Mnemoverse account, who pays an invoice, or whether a configured login still works. These are the three paths implemented in the source baseline:

Wide tables: scroll horizontally to see more columns.

A configured path is not proof of verified credentials or operational readiness. The installation must support and permit that path. An explicit request cannot bypass repository, private-repository, executor or Off gates. Existing runs keep what they actually used rather than inheriting today's configuration.

The Claude login path defaults to the owner's enabled installation; an operator can restrict it further to listed repositories. The Codex login path always needs an explicit repository list and trusted private visibility.

Mnemoverse sign-in, GitHub access and model-provider authorization are separate. Signing into your profile does not authorize Claude or ChatGPT subscription use. Provider credentials are not accepted in PR comments or the profile editor.

What each path costs you

• API stages: Sigma's API accounting records known (settled) and held (reserved, unsettled) amounts. They are token-derived estimates, not invoices.
• Subscription stages: recorded CLI usage may include an estimate at API list price. That observation is not billed by Sigma and is not counted against its API spending cap. It does not state the provider's subscription price or remaining plan allowance.
• Mixed runs: the Claude producer's observed usage and the verifier's metered API cost must be read separately. Neither is the total price of a subscription.
• Two-subscription runs: both stages can have separate observations. Missing stage usage or estimates mean unavailable information, not zero usage. The run page can retain known observations while showing that other estimates are absent.

The stage details show the recorded executor and usage. They do not identify the viewer as the subscription owner or payer. See Cost lines and the run page.

Provider constraints

Technical support for a login does not grant permission to offer it commercially. The following provider documentation was checked on 1 October 2026:

• Anthropic: end users can sign into an unmodified Claude Code binary through Anthropic's own flow under the conditions for hosting that binary. This does not permit a third-party app to collect Claude credentials, intermediate subscription usage, or offer its own Claude.ai login. The applicable arrangement must satisfy the provider's terms. Anthropic legal and compliance.
• OpenAI: Codex supports API-key and ChatGPT sign-in; API usage is billed separately from a ChatGPT subscription. Its authentication guide recommends API keys for programmatic CI/CD. Codex authentication.
• Sign in with ChatGPT is a separate identity/token-sharing integration, with explicit eligibility for locally hosted/open-source and selected commercial applications. It is not a synonym for copying a personal Codex login, and Sigma has not implemented it here. Token sharing, integration quickstart.

These links describe provider requirements. This guide does not claim that Sigma's current hosted or paid subscription arrangement has been approved.

Usage windows and waiting

A subscription attempt can reach its provider's usage window. When the run has a reported reset within Sigma's supported waiting window and waiting is enabled, the affected job can wait for automatic resumption. Consecutive waits are bounded; a new attempt retains the refused run in history. The status names the provider and reset time. A scheduled resumption is not a promise of a successful review. Other reviewers are not evidence that this login is ready. A missing or distant reset can instead leave the run unfinished with recovery guidance.

Read the specific job's status rather than inferring a global plan limit from a single refusal. Limits and budget explains the recovery choices and which actions require the maintainer.

Choosing a reviewer for one request

A repository writer can request an exact configured reviewer by commenting:

/sigma review <reviewer>@<version>/<executor>

The registered App-mention form also accepts a selector. Use the identity shown for your repository, not a version copied from an older example. The controller resolves only trusted registered constructions, with a compatible lineage/executor already configured there. Arbitrary profiles, model routes and free text cannot change execution authority.

Off is not bypassed by naming a reviewer. A subscription-only roster does not authorize selecting an API reviewer. An unknown, disabled or unavailable selector receives a neutral Reviewer selection refused check, without model work. Changing schedules for configured reviewers is supported; changing the execution roster is not supplied by those mode controls.