Architecture
One foundation. Products built on it. Outcomes inside your estate.
Nexus is a single execution foundation for workflows, integration, code, sovereign AI, human decisions and infrastructure. Products are built on that foundation, and everything runs where your data, credentials and evidence already live.
Execution path
The same path carries a finance process, an infrastructure change and a security response. Only the steps in between differ.
- foundation, products, outcomes
- 3 layersfoundation, products, outcomes
- agnostic packaging
- Kubernetesagnostic packaging
- data, models and secrets
- Your estatedata, models and secrets
- per execution
- One recordper execution
Mental model
Three layers, described plainly.
Most platform diagrams hide the question buyers actually ask: what is shared, what is packaged and what does the organization end up with. These three layers answer it.
Layer 01
Platform foundation
The execution capability: workflow engine, connectors, code, functions, triggers, infrastructure actions, sovereign AI, identity, secrets and observability.
Layer 02
Products on Nexus
Atlas, Cerberus, Foundry, Sentinel and Shield are built on the foundation. They can be adopted on their own, and they inherit the same identity, secret handling and audit behaviour.
Layer 03
Outcomes
Business automation, AI operations, infrastructure operations and security outcomes, delivered inside the customer estate rather than in a vendor tenant.
Diagram
The stack in one view.
Read it from the bottom. The foundation provides execution, products package it, and the top layer is what the organization gets.
Outcomes inside the customer estate
- Business automation
- AI operations
- Infrastructure operations
- Security outcomes
Products on Nexus
- Nexus Atlas
- Nexus Cerberus
- Nexus Foundry
- Nexus Sentinel
- Nexus Shield
Nexus platform foundation
- Workflow engine
- Connectors
- Code nodes
- Functions and services
- Triggers and event sources
- Infrastructure actions
- Sovereign AI
- Identity and access
- Secrets
- Observability and audit
Runs inside your boundary
- Kubernetes
- Identity provider
- Secret store
- Storage
- Model hosting
- Observability
- Network policy
Layer 01
What the foundation provides.
These capabilities are shared. A workflow, a product and an infrastructure operation all draw on the same engine, the same credentials model and the same execution record.
Workflow engine
Executes the process graph, handles branching, retries, long-running waits and the state a run carries between steps.
Connectors
Prebuilt actions against enterprise applications, databases, cloud platforms and services, with typed inputs and outputs.
Code nodes
Real code inside the workflow across eight runtime families, for the logic that no prebuilt action covers.
Functions and services
Reusable logic and long-lived services that workflows call, so common capability is written once.
Triggers and event sources
Webhooks, schedules, queues, message topics, file and repository events, and infrastructure events that start work.
Infrastructure actions
Kubernetes operations, infrastructure as code runs and cloud provider actions treated as ordinary workflow steps.
Sovereign AI
Model registry, endpoints, knowledge bases and retrieval running inside the customer environment.
Identity and access
Single sign-on, directory integration, roles, workspaces and separation of duties applied at run time.
Secrets
Vault-backed credentials resolved during execution and referenced, never embedded, in workflow definitions.
Observability and audit
Execution history, per-node results, approval records, metrics and log export to the platforms you already run.
Layer 02
Products built on the same foundation.
Each product delivers a defined capability. Because they sit on the platform, adopting one does not create a separate governance model to maintain.
Nexus Atlas
External attack-surface assurance, delivered as a packaged product on the same foundation.
Nexus Cerberus
AI application security and posture management for the models and applications you operate.
Nexus Foundry
The governance and self-service module: a governed catalog, policy-driven approvals and provisioning through Nexus workflows.
Nexus Sentinel
Sovereign SIEM and SOAR, with detection and response running inside the customer estate.
Nexus Shield
Self-hosted application and API protection for the services you expose.
Layer 03
What the organization ends up with.
The point of the architecture is not the platform. It is the set of operations that can now run reliably, with approval and evidence, inside the estate.
Business automation
Cross-system processes in finance, supply chain, service and back-office operations, executed with approvals and evidence.
AI operations
Classification, extraction, summarization and assisted reasoning applied inside governed workflows on private data.
Infrastructure operations
Provisioning, deployment, remediation and environment lifecycle driven by business events and approvals.
Security outcomes
Exposure assessment, detection and response, and protective controls delivered through packaged products on the platform.
Execution path
How work moves through the platform.
Whatever the process, execution follows the same path. That consistency is what makes governance and evidence uniform across very different kinds of work.
- 01
Trigger
An event source, schedule, API call or user request starts a run with its originating identity attached.
- 02
Integration
Connector, API, protocol and database steps retrieve the data the process needs from the systems that hold it.
- 03
Rules + Code
Deterministic logic and code nodes validate, transform, calculate and decide what happens next.
- 04
Sovereign AI
Self-hosted models classify, extract, summarize or reason over the assembled data, with retrieval from private knowledge.
- 05
Human Approval
The run pauses at an approval node where an authorized reviewer confirms, corrects, rejects or escalates.
- 06
System Action
The authorized change is written back to applications, databases or infrastructure using vault-backed credentials.
- 07
Audit
Inputs, outputs, model results, decisions and responses are retained as a single execution record.
- 08
Feedback
Recorded decisions and corrections become material for improving rules, routing and prompts in a later revision.
Conceptual separation
Control plane and execution plane.
It helps to separate the part of the platform that holds definitions and decisions from the part that performs work. Both run inside your environment.
Control plane
Definition and governance
- Workflow definitions, revisions and publishing state
- Workspaces, roles and permission assignment
- Connection configuration and secret references
- Catalog entries, policies and approval routing
- Execution history and the audit record
Execution plane
Doing the work
- Running workflow instances and their state
- Connector, API, protocol and database calls
- Code node and function execution
- Model inference against hosted endpoints
- Infrastructure actions against target environments
The separation is conceptual and is described here to make deployment and network planning easier. Specific component topology is confirmed during an architecture session against your environment rather than asserted in general.
Runtime footprint
What the platform expects from the environment.
Nexus is designed to consume the infrastructure you already operate rather than to introduce a parallel stack alongside it.
Kubernetes-agnostic
The platform is packaged to run on standard Kubernetes. It does not depend on a specific managed service, so the same deployment model applies in a data center, a private cloud or a sovereign cloud region.
Services and functions
Platform services and workflow execution scale as workloads in the cluster. Reusable functions and long-lived services are deployed alongside them and called from workflows.
Event sources
Webhook endpoints, schedulers, queue and topic consumers, repository hooks and infrastructure events feed the engine. Ingress and network exposure follow your existing policy.
Vaults and identity
Secrets resolve against the secret store you operate, and authentication is delegated to your identity provider and directory rather than duplicated in the platform.
Storage
Execution history, workflow definitions, artifacts and knowledge indexes use storage provisioned in the same environment, under your backup and retention policy.
Observability
Metrics, logs and events are exported to the monitoring stack already in use, so platform behaviour appears where operations teams are looking.
Where things live
Data, credentials, models, knowledge and evidence.
In a customer-controlled deployment, the answer to each of these is the same: inside the boundary you already defend.
Business data
Data retrieved during a run stays within the deployment and the systems it came from. There is no requirement to copy it to a vendor tenant for the platform to work.
Credentials
Secrets are held in the secret store you operate and resolved at execution time by the platform running in your cluster.
Models
Model artifacts and inference endpoints are hosted in your environment, including in disconnected deployments, with no external model API dependency.
Knowledge
Documents and indexes used for retrieval are built and stored locally, so private knowledge is never sent out for embedding or search.
Audit evidence
Execution history, per-node results and approval records live in platform storage inside the deployment, and can be exported to your archive.
Definitions
Workflows, functions, catalog entries and policies are held in the deployment and can be promoted between environments under your change process.
Architecture session
Map the architecture onto your environment.
Bring your Kubernetes distribution, identity provider, secret store and network boundaries. We will walk through how the platform would be deployed and where each part of the execution record would live.