Nexus Plugin Architecture
How Aura keeps domain semantics (IoT, AI) out of the verifier core.
Why plugins?
Aura’s verifier is intentionally small and generic. Domain-specific meaning (like MMIO rules or tensor shape contracts) is implemented in Nexus plugins, not hard-coded into the verifier.
This makes the system:
- easier to extend
- easier to audit
- safer to gate (trust)
Built-in plugins
This repository includes two built-ins:
aura-iot: hardware/MMIO safety (caps, offsets, masks)aura-ai: tensor/ONNX shape checks
Plugin docs:
/docs/plugins/aura-iot/docs/plugins/aura-ai
Enabling plugins (aura.toml)
Plugins are enabled via aura.toml and are trust-gated:
TOML
plugins = [
{ name = "aura-iot", trusted = true },
{ name = "aura-ai", trusted = true },
]
If a plugin is listed but not trusted, the LSP/CLI will refuse to run it.
Proof notes → editor feedback
Plugins can record successful proof facts (not only failures). The verifier returns them in a verification report, and the LSP publishes them as informational diagnostics.
Aura Sentinel uses this metadata to show:
- gutter icons per plugin
- hovers with mask/range and the SMT formula (when available)
- inlay hints for inferred ranges