113 lines
4.7 KiB
Markdown
113 lines
4.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.
|
|
|
|
## 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.
|
|
|
|
## 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.
|
|
|