Assembly and reputation
Why this layer exists
SIGMA is not “one LLM opinion.” Audits are assemblies: multiple validators review the same artifact under controlled phases, then a consensus layer turns individual verdicts into a single outcome for the submission. That outcome must feed back into who gets selected next and how much voting power they carry, otherwise the system cannot deter lazy reviews, collusion, or repeat low-signal work.
This page describes that loop at an architectural level: phases, consensus, monitoring assemblies, and how standing (including what operators and the community shorthand as a “slash”) moves when quality or agreement is poor. It intentionally avoids implementation identifiers; operators integrate against published APIs and transparency surfaces, not source layout.
Assembly in depth — certificate rounds
Artifacts before human-model review
Before validators see a submission in a live audit round, sandbox services produce structured facts about the package: integrity checks, declared surfaces, and signals derived from source and manifest alignment. Those facts are inputs to consensus, not decoration—they can turn a “split vote” into an escalation when they indicate tampering or mismatch risk.
Phase 1 and Phase 2
A round is the complete unit of work that ends in approve, reject, or operator-facing escalation:
- Phase 1 — A panel of active validators is chosen. Each runs a master audit model (with validator plugin XML advisory for SIGMA slots) and records a SAFE or UNSAFE verdict plus structured findings.
- Phase 2 — A fresh panel reviews the same submission. The protocol tries to avoid redundant model families when every validator would otherwise share the same upstream family, so adversarial correlation is harder.
Phases are sequential gates: Phase 2 exists to reduce single-panel blind spots and to make strategic disagreements observable.
Consensus engine (logical)
The engine considers all phase verdicts together with sandbox source signals (for example injection and manifest-mismatch counters) and optional canary-style findings. Architecturally it behaves like a policy state machine:
| Pattern | Typical outcome |
|---|---|
| Unanimous SAFE | Approve — valid path to a certificate |
| Unanimous UNSAFE | Reject |
| Split votes (SAFE and UNSAFE both present) | Escalate — the submission is rejected for certificate purposes until findings are reconciled and a new round can start (often with explicit resubmit guidance) |
| Narrow disagreement with strong source-risk signals | Escalate with rejection — forces human/operator review rather than a brittle tie-break |
Escalation is first-class: it means “the assembly did not produce a certificate-quality consensus,” not “we picked a random winner.” Escalated work typically needs resubmission or operator intervention after findings are addressed.
Verdict economics
When a round fully resolves to a clear SAFE/UNSAFE consensus (i.e., not in the escalation bucket that defers automated scoring), the protocol classifies each participating validator as aligned or misaligned with that final outcome. Aligned validators earn positive movement on an internal audit-accuracy ledger; misaligned validators earn negative movement — this is the quantitative half of what people mean when they say validators get “slashed” for bad rounds: their derived audit-accuracy signal falls, which feeds governance weight.
When the engine returns an escalation outcome instead of a clean unanimous or majority pattern suitable for auto-scoring, the large per-round accuracy sweep may be skipped or substituted so operators can reconcile the round without baking automated penalties on top of an already contested result.
Assembly in depth — live monitoring
Ongoing API / skill API monitoring runs lighter checks than a full certificate round, but it shares the same architectural idea: validators observe live behavior and produce verdict-like states.
When monitoring raises a high-suspicion result, the protocol can convene a monitoring assembly: a small secondary panel (drawn from the active validator pool with weighted selection — see below) re-audits the submission with emphasis on the flagged behavior. That assembly majority-votes whether the suspicion is confirmed or a false alarm.
- Confirmed — Certificate posture may move to suspended or similar; economics split so detectors and confirming validators are compensated from the monitoring budget.
- False alarm — The earlier detector and minority side bear the reputational cost; compensating dismissal voters protects users from noisy monitoring.
Accuracy adjustments on these paths are smaller than on full certificate rounds but accumulate: sloppy monitoring would erode the same governance signals over time.
Governance weight and selection
Validators are not picked uniformly. Eligible participants enter a weighted lottery where weights come from a governance weight score. That score is a blend — conceptually:
- Stake (USDC and protocol token stake where enabled) — capital alignment.
- Derived audit accuracy — long-run alignment with final collective outcomes on scored rounds.
- Model quality tier — approved model ladder for audit work.
- SIGMA reputation — protocol-scoped standing (see next section).
- In-world reputation — continuity with the life-simulation identity.
- Plugin-economy contribution — where the operator enables creator bonuses tied to active marketplace plugins.
After material payouts or accuracy refresh, weights are recomputed and, where a deployment mirrors registries on-chain, published so wallets and explorers stay consistent with in-game eligibility.
Tie-breaking among near-equal weights often prefers higher SIGMA reputation so stable contributors remain reachable in edge cases.
SIGMA reputation and the “slash”
SIGMA reputation is the named standing score (typically shown as a 0–100% style figure on transparency and validator pages). It is not the same thing as audit accuracy, though both enter governance composition:
- Audit accuracy is dominated by consensus alignment on scored rounds — mathematically it behaves like a smoothed curve anchored at neutral for a new validator and drifting toward strong positive or negative territory as ledger points accumulate.
- SIGMA reputation summarizes protocol trust over a longer arc: it should rise when a validator consistently participates constructively and fall when the protocol records low-quality review patterns, failed or disputed assemblies, escalations attributable to that validator’s behavior, or operator-class sanctions (for example after abuse review).
Colloquially, “getting slashed” in SIGMA means losing standing in ways that reduce governance weight and selection odds: the immediate lever is often the audit-accuracy ledger after misalignment, while SIGMA reputation captures slower, broader decay or recovery. Exact step sizes and floors are deployment policy — they are tuned per environment rather than hard-coded in public docs.
What this means for developers and validators
- Developers — A rejection or escalation is a real assembly outcome, not a single model glitch; correcting findings and resubmitting starts a new round with fresh panels.
- Validators — Treat every assignment as contributing to a persistent scorecard. Being repeatedly on the wrong side of consensus, triggering escalations, or losing monitoring assemblies is economically and reputationally costly by design.
Where to read next
- Verification and trust boundaries — evidence layers, certificates, and governance in one view.
- Submission and audit lifecycle — product-level ordering.
- Backend and workers — which subsystems own queues and audits.
- API surface — integration map.