How It Works

Three mechanisms. Four specialists. One Quorum.

SDNS is the meta-control plane framework built into the four specialist products you run. The databus, the AI Quorum, and the event federation are capabilities that exist inside NIVMIA, IVMIA, OpenUTM, and VaultSync — each running its own local-inference AI in its own specialty. When you run them together, those capabilities connect and the Quorum emerges.

1. The Databus — shared knowledge

Every product publishes what it knows. Every product can query what the others know.

The databus is a shared data contract — not a separate service. Each product implements it internally and exposes the same five views through a standard REST API.

The databus is not middleware. It is not a message broker. It is a data contract: five views (hosts, networks, assets, workloads, health) that every product agrees to publish. Each product stores its own data in its own database, and exposes it through a standard API. When NIVMIA discovers a new switch, that switch appears in the hosts view. When IVMIA migrates a VM, the workloads view updates. No central server required. No new infrastructure to maintain.

2. The AI Quorum — shared reasoning across specialties

Four specialist AIs, each running local inference in its own specialty, reaching consensus across networking, compute, security, and data protection.

Each product runs its own local-inference AI — powered by Ollama models on each appliance, under your control. Customer data never leaves the appliance. Each specialist AI analyzes its own specialty: NIVMIA spots network anomalies, OpenUTM detects security patterns, IVMIA recommends VM placement, VaultSync optimizes backup schedules.

SDNS is where those four specialists reach a Quorum through the databus. The question changes from "what's wrong in my specialty?" to "what's happening across the whole infrastructure?"

Decisions that cross domains

Some decisions require knowledge from more than one specialty. "Should we migrate this VM to a different host?" requires understanding of: network bandwidth to the target (NIVMIA), available compute resources (IVMIA), security group membership (OpenUTM), and whether the backup schedule needs adjustment (VaultSync). No single product has all the answers. Through the databus, the four AIs assemble the full picture and reach a coordinated recommendation — the Quorum is where that question gets answered.

The human still approves. The Quorum assembles the context and recommends. But instead of a human spending 30 minutes correlating four dashboards, the four AIs do it in seconds and present one recommendation with supporting evidence from every specialty.

3. Event Federation — shared awareness

When something happens in one product, the others hear it and can respond.

Real-time cross-product events

Each product publishes events about things that matter to the others. Not every internal event — only the ones that cross domains:

NIVMIA detects a link failure → OpenUTM adjusts firewall rules for the backup path, IVMIA considers migrating affected VMs, VaultSync reschedules backups that would traverse the failed link.
OpenUTM blocks a confirmed intrusion → NIVMIA isolates the switch port, IVMIA snapshots the affected VM for forensics, VaultSync verifies backup integrity for the compromised host.
IVMIA detects a host running hot → NIVMIA checks the network path to alternate hosts, OpenUTM pre-configures security groups for the migration target, VaultSync confirms the target host's backup policy.
VaultSync detects backup corruption → NIVMIA checks network integrity on the storage path, IVMIA flags the source VM for inspection, OpenUTM logs the event for compliance.

These aren't scripted runbooks. They are products that understand each other's vocabulary, published through the event bus, and acted upon by each product's own logic. The cross-product communication happens through the same federation mechanism that already exists for multi-site deployments.

What doesn't change

Every product works standalone. NIVMIA manages your network today, without IVMIA or OpenUTM or VaultSync. SDNS capabilities activate when products are connected. They don't degrade when they're not.
No new infrastructure. The databus, AI agents, and event system are built into each product. There is no "SDNS server" to deploy, no message broker to maintain, no central point of failure to worry about.
Each product upgrades independently. Versions are loosely coupled. The databus contract is stable across versions. You upgrade NIVMIA without touching IVMIA.
Your data stays under your control. AI runs alongside your products. Events flow between your own appliances. The databus queries stay within your environment. Nothing leaves your trust boundary.