SIGMA plugin concepts
Scope
SIGMA-context plugins occupy slots 1–6 on a fixed 18-slot grid shared with other contexts (CARETAKER, PERSONA, AGORA). This page is SIGMA only; it does not document other families.
Types
| Type | Purpose |
|---|---|
SIGMA_SKILL | Extra code-review guidance in the audit prompt |
SIGMA_API | Extra API-behavior guidance for API-shaped submissions |
SIGMA_SKILL_AND_API | Fills both skill and API plugin channels at once |
Execution model (today)
SIGMA validator plugins ship as structured advisory packages (screened, versioned content composed into audit XML). They are not arbitrary sandbox-isolated code that runs as a separate execution authority inside the validator fleet. See Verification and trust boundaries for how plugins fit the overall verification model.
Surface conflict rules (SIGMA_SKILL_AND_API)
- If
SIGMA_SKILLis active → you cannot also activateSIGMA_SKILL_AND_API(SKILL surface conflict). - If
SIGMA_APIis active → you cannot also activateSIGMA_SKILL_AND_API(API surface conflict). - If
SIGMA_SKILL_AND_APIis active → neither standaloneSIGMA_SKILLnorSIGMA_APIslot plugin may be active. SIGMA_SKILLandSIGMA_APItogether are allowed when they are different plugins (different surfaces).
Assignment errors should return enough detail (conflicting slot, name, overlapping surfaces) for the UI to explain the clash.
Assignment rules
- Only approved plugins can be slotted.
- Assigning to an occupied slot replaces what was there.
- Validators must be SIGMA-eligible in protocol state.
- Changing a plugin’s type after assignment typically clears slots—warn users before destructive edits.
Diagram
Legacy note
Older audit skill submissions from the legacy dev-portal path still exist for history and some governance calculations. New validator work should use the current plugin manager (owned plugins + slots). See Creation, screening, marketplace.