How it works

A conceptual view of the mesh — enough to evaluate the architecture without publishing operator runbooks or internal ports.

Data Nexus is built as a hub-and-spoke platform with an explicit split between administrative control and inference traffic. Day-to-day management does not share the same hot path as model serving.

Control plane and data plane

Applications & operators │ ▼ ┌─────────────┐ │ Edge gateway │ TLS termination, ingress policy └──────┬──────┘ │ ┌───────┴────────┐ ▼ ▼ Control plane Data plane (identity, (inference proxy registry, to approved policy) services) │ │ └───────┬────────┘ ▼ Node agents + AI services (SDK registration & telemetry)

Control plane — identity, service registry, policies, and administration.
Data plane — high-throughput path that routes consumer calls to healthy, approved services (on-prem or connected cloud).
Edge gateway — secure external entry for both admin and inference HTTPS traffic.
Node agents — per-machine agents that help services join the mesh and report infrastructure health.

How services join the mesh

Customer AI microservices integrate through the Syva Service SDK. The SDK talks to the local Node Agent, which participates in registry sync with the control plane. Services advertise a stable name, host, and port; operators approve lifecycle before production traffic.

Deploy your inference service on a worker that runs a Node Agent.
Configure the SDK and register on startup; keep a heartbeat while running.
Deregister on shutdown so routing stops promptly.
Once active, consumers call the service through the governed proxy path.

How applications consume AI

Applications do not call each model port directly. They use one HTTPS proxy pattern with scoped API keys:

https://<your-nexus-host>/v1/proxy/<service-name>/<path>

Logical groups can expose multiple replicas under a shared route when you run pooled capacity. Keys limit which services (or groups) a consumer may call, with rate limits and audit visibility for operators.

Physical and virtual services

Type	Role
Physical services	Your containers or processes on private infrastructure — registered via the Service SDK
Virtual connectors	Approved external AI APIs brought under the same governance channel (credentials stay server-side)

Security posture (public view)

Separate control and inference paths
Scoped consumer API keys and service registration trust
Registry approval workflows and emergency registration lockdown
Self-hosted deployment — no mandatory vendor SaaS control plane

Detailed firewall, settings, and certificate procedures are provided during architecture reviews and pilots — not on the public site.

What this enables for applications

Products such as Voice AI Agent and MeetInsight consume governed inference through the same foundation. Knowledge AI is on that plane and is not live yet. Session and conversation primitives support multi-turn agent experiences; vector memory is available as a foundation for knowledge-grounded workloads.

Next: implement a service with the Service SDK guide, or return to the platform overview.