149 lines
6.7 KiB
Markdown
149 lines
6.7 KiB
Markdown
# Nexus One AI - Enterprise Platform Datasheet
|
|
|
|
## Customer edition
|
|
|
|
Nexus One AI is a private enterprise AI platform deployed on customer-controlled
|
|
infrastructure. It brings conversational AI, governed enterprise knowledge,
|
|
document intelligence, prompt management, evaluation, automation, application
|
|
development and operational controls into one managed platform.
|
|
|
|
## Customer value
|
|
|
|
- Keep prompts, documents, application data and AI workloads inside the approved customer boundary.
|
|
- Standardize AI access through one identity, governance and operations model.
|
|
- Turn enterprise content into cited, reviewable answers and reusable outputs.
|
|
- Build agents, workflows and governed applications without creating isolated pilot stacks.
|
|
- Operate AI with health monitoring, logs, audit, backup and lifecycle controls.
|
|
- Support connected, restricted-network and air-gapped deployment patterns.
|
|
|
|
## Platform design principles
|
|
|
|
- Customer-authoritative identity, data, infrastructure, models and operating policy.
|
|
- Durable business and execution state independent of queues and worker processes.
|
|
- Least-privilege access for users, services, applications and integrations.
|
|
- Replaceable inference through a logical model gateway.
|
|
- Truthful degraded and failure states instead of simulated success.
|
|
- Versioned, reviewable and recoverable applications, packs and platform changes.
|
|
- Signed offline delivery for approved releases, models and capability packs.
|
|
|
|
## Reference architecture
|
|
|
|
Users access a single TLS origin and authenticate through enterprise identity.
|
|
The Nexus portal exposes AI workspaces and administration. A protected Core API
|
|
applies policy, manages durable state and routes AI work. PostgreSQL with vector
|
|
search stores authoritative platform data; RabbitMQ supports durable background
|
|
work; MinIO stores governed objects and artifacts. Model execution is accessed
|
|
through a logical gateway to an approved local or customer-selected compatible
|
|
inference provider. Kubernetes isolates services, applications and extensions.
|
|
Prometheus, Alertmanager, Grafana, Loki and Alloy provide operational visibility.
|
|
|
|
## Kubernetes and background platform
|
|
|
|
Nexus One AI is packaged as a Kubernetes application platform. K3s provides the
|
|
compact Kubernetes distribution for appliance and single-node deployments,
|
|
while customer-specific enterprise designs can use an approved multi-node
|
|
topology. Namespaces separate platform services, data, observability, developer
|
|
workspaces, application previews and capability packs.
|
|
|
|
Stateless platform services run as Deployments. PostgreSQL, RabbitMQ and MinIO
|
|
provide durable state, background-job transport and object storage. Services
|
|
provide stable internal addresses; Ingress exposes only approved browser and API
|
|
routes. ConfigMaps hold non-sensitive configuration and Secrets hold protected
|
|
credentials. Jobs, CronJobs and persistent volumes support maintenance,
|
|
scheduling, evidence and retained data.
|
|
|
|
Interactive requests enter through TLS ingress, pass identity and role policy,
|
|
and reach the portal or Core API. Long-running work is recorded in PostgreSQL,
|
|
queued through RabbitMQ, executed by workers, and stored as durable status and
|
|
artifacts. Prometheus, Alertmanager and Grafana provide metrics and alerting;
|
|
Alloy and Loki provide logs. Backup services protect databases, objects,
|
|
configuration and approved workspace data and support restore verification.
|
|
|
|
App Studio applications execute in isolated Kubernetes preview namespaces before
|
|
independent review and release through the application gateway. Capability packs
|
|
also follow signed import, validation, enable, upgrade, rollback and removal
|
|
lifecycles.
|
|
|
|
## Capability domains
|
|
|
|
### Work with AI
|
|
|
|
- Enterprise AI Workspace
|
|
- Prompt Studio and governed Prompt Library
|
|
- Model comparison, evaluation suites, RAG quality and feedback review
|
|
- Team Chat Rooms and Meeting Assistant
|
|
|
|
### Enterprise knowledge and documents
|
|
|
|
- Private-by-default Nexus Notebook collections
|
|
- Evidence-grounded questions with citations
|
|
- Document ingestion, extraction, indexing and governed outputs
|
|
- Multi-format Document Compare
|
|
- Document digitization with human review
|
|
- Dataset creation and controlled model-training requests
|
|
|
|
### Automate and build
|
|
|
|
- Agent Studio
|
|
- Workflow Designer
|
|
- Schedules and durable run history
|
|
- App Studio with isolated previews, review, publish and rollback
|
|
- Application gateway and reusable template marketplace
|
|
- Python/TypeScript SDKs, Jupyter and governed APIs
|
|
|
|
### Govern and operate
|
|
|
|
- Keycloak-based identity and role enforcement
|
|
- Users, teams, assigned reviews and approval boundaries
|
|
- Model catalog and logical model routing
|
|
- API credentials, guardrails and audit activity
|
|
- Governed connectors and MCP capability projection
|
|
- Signed Pack Manager lifecycle
|
|
- Platform, GPU, database, job and application monitoring
|
|
- Backup, restore verification and support evidence
|
|
|
|
## Data and trust boundaries
|
|
|
|
Nexus One AI is designed so customer information remains within the approved
|
|
deployment boundary. Browser clients do not receive connector secrets. External
|
|
integrations use server-side credentials, allowlisted hosts and bounded
|
|
capabilities. Generated applications and extensions operate in isolated
|
|
Kubernetes boundaries and follow explicit review and acceptance lifecycles.
|
|
|
|
## Deployment profiles
|
|
|
|
- Nexus One AI Workstation: individual specialists and compact local deployments.
|
|
- Server S: contained team or departmental introduction.
|
|
- Server M: sustained departmental operations and broader automation.
|
|
- Server L: multi-team use, larger knowledge workloads and advanced governance.
|
|
- Server Max: custom enterprise, multi-GPU or specialized infrastructure design.
|
|
|
|
Final sizing depends on model choice, quantization, context length, concurrency,
|
|
document volume, latency target, storage retention and resilience requirements.
|
|
|
|
## Customer implementation
|
|
|
|
1. Discovery and workload definition
|
|
2. Security, identity and infrastructure assessment
|
|
3. Solution sizing and deployment profile
|
|
4. Platform installation and configuration
|
|
5. Data onboarding and integration
|
|
6. Acceptance testing and operational handover
|
|
7. Adoption, support and controlled expansion
|
|
|
|
## Customer prerequisites
|
|
|
|
- Approved compute, storage and network design
|
|
- Customer identity and role model
|
|
- Customer PKI and certificate requirements
|
|
- Approved inference models and accelerator capacity
|
|
- Data classification, retention and DLP policies
|
|
- Backup destination and recovery objectives
|
|
- Connector credentials, scopes and data-boundary approvals
|
|
- Named platform, security and business owners
|
|
|
|
Specific capability availability depends on the licensed edition, purchased
|
|
packs, customer infrastructure and approved integration scope. Final architecture,
|
|
sizing, security configuration and acceptance criteria are confirmed during the
|
|
solution-design process.
|