SDNS Vision How It Works Sovereignty Safer Together Integration Use Cases
The meta-control plane — an AI Quorum for multi-vendor infrastructure

Four specialists. One conversation.

DEC SDNS is the meta-control plane that sits above NIVMIA, IVMIA, OpenUTM, and VaultSync — four specialist products, each running its own local-inference AI in its own specialty. SDNS is where the four AIs reach decisions that cross domains, which no single product can make alone. "Is this VM safe to migrate?" needs bandwidth, compute, security-group, and backup-chain knowledge at once. The Quorum is where that question gets answered.

SDNS is the meta-control plane — federation, not orchestration.

Each DEC-LLC product is a specialist in its own specialty. NIVMIA knows your network. IVMIA knows your virtual machines. OpenUTM guards your perimeter. VaultSync protects your data. Each one runs its own local-inference AI, independently, and does its job well.

But infrastructure doesn't live in silos. A firewall rule change affects which VMs can talk to which switches. A storage migration changes which backup jobs need to run. A new VLAN on the network means new security groups on the firewall. These decisions that cross domains happen every day — and today, a human carries them between dashboards.

SDNS is the shared data contract that lets the four specialist AIs talk to each other and reach a Quorum. Through a shared databus, through AI agents that can reason across domains, and through an event system that lets each product respond to what the others are doing — specialists stay sovereign in their specialty, and the boundary gets crossed by agreement.

What SDNS actually is

It is the databus — a shared data layer where every product publishes what it knows (hosts, networks, assets, workloads, health) and every product can query what the others know.

It is the AI Quorum — four specialist AIs, each running local inference on its own appliance, reasoning together across networking, compute, security, and data protection. "Should we migrate this workload?" is not a question any single product can answer. It requires knowledge of network capacity, VM resources, security policy, and backup state. The Quorum is where that question gets answered.

It is the event bus — when NIVMIA detects a link failure, OpenUTM can reroute traffic. When IVMIA migrates a VM, VaultSync adjusts its backup targets. When OpenUTM blocks an intrusion, NIVMIA quarantines the switch port. These are not scripted integrations — they are products that understand each other's events and respond.

What SDNS is not

SDNS doesn't override the specialists — each product owns its specialty. There is no message broker, no central server, no customer data leaving the appliance. The databus lives inside each product. The AI agents run local on each appliance. The event system lives inside each product. SDNS is the framework that emerges when you run them together.

Think of it this way: you don't install "harmony" into an orchestra. Harmony is what happens when the musicians listen to each other.

The three things that make SDNS real

1

The Databus

A shared data contract across all products. Five standard views — hosts, networks, assets, workloads, health — that every product publishes and every product can query. When NIVMIA discovers a new switch, IVMIA can see it. When VaultSync finishes a backup, NIVMIA can report it. No custom integrations. No glue code. One data contract.

2

The AI Quorum

Four specialist AIs — each running local inference on its own appliance, under your control, not a third party's — reaching consensus across networking, compute, security, and data protection simultaneously. They can recommend, advise, and (with your approval) act: migrate a workload, adjust a security group, reroute traffic around a failure. Decisions that used to require a human to correlate four dashboards.

3

Event Federation

When something happens in one product, the others can hear it and respond. Not through polling. Not through scheduled syncs. Through real-time events that flow between products. A detected intrusion triggers network isolation. A capacity warning triggers workload rebalancing. A certificate expiration triggers coordinated renewal.

What this means in practice

Today: four dashboards, one human

Your infrastructure sees itself in fragments.

NIVMIA knows a switch port is dropping packets. IVMIA knows a VM is struggling. OpenUTM knows traffic is being rerouted through a backup path. VaultSync knows the backup window is being missed. Four products, four views, four conclusions — and a human who has to stitch them together to realize: the root cause is a single failing uplink.

With SDNS: one conversation, one conclusion

Your infrastructure sees itself whole.

The databus means every product has the full picture. The Quorum correlates across specialties: failing uplink → degraded VM performance → rerouted traffic → missed backup window. It recommends: migrate the affected VMs to a host on a healthy uplink, update the firewall rules to match, and reschedule the backup. One recommendation. One approval. Four specialists act in concert.

The SDNS ecosystem

The four core products are the foundation. Specialized capabilities extend the conversation.

Core Four

NIVMIA (network), IVMIA (compute), OpenUTM (security), VaultSync (data protection). Each publishes to the databus. Each listens to the event bus. Each runs its own local-inference AI in its own specialty, and each participates in the Quorum when a decision crosses domains.

IPv6Auto

Automatic IPv6 addressing and transition management. Runs as an OpenUTM plugin. Publishes address assignments to the databus so NIVMIA and IVMIA see the full dual-stack picture without manual configuration.

FireMigrate

Firewall rule migration between vendors. Reads security policy from one platform, translates and applies it to another. Uses the databus to verify that migrated rules reference real hosts and networks — not stale entries from a spreadsheet.

Future members: credential federation, external identity bridging, certificate lifecycle management — each delivered as capabilities within existing products, not as separate installations.

Architectural, not feature-deep.

The Quorum isn't a feature bolted onto a product — it's a property of how the four specialists were designed together. Forty years of infrastructure engineering sits under the surface.

How the Databus Works Real Scenarios