docs: document live Nexus 155 features and architecture
This commit is contained in:
Jino Jose committed
1 parent
4f1419ca93
commit
709c0678ec
4 files changed
+386
-92
No files matched your search
@@ -0,0 +1,278 @@
|
||||
# Nexus One AI - Live Features and Architecture Reference
|
||||
|
||||
**Environment:** `172.16.10.155`
|
||||
**Evidence date:** 1 September 2026
|
||||
**Audience:** technical buyers, solution architects, implementation teams and operators
|
||||
**Lifecycle:** Enterprise Pilot / provisional Gate 10
|
||||
|
||||
## 1. Purpose and evidence standard
|
||||
|
||||
This document describes the Nexus One AI platform observed on `.155`. It is
|
||||
based on live Kubernetes inventory, the deployed portal and runtime source,
|
||||
release artifacts, health probes, and current readiness, security and backup
|
||||
evidence. It distinguishes implemented capabilities from gated, provision-only
|
||||
or unhealthy paths.
|
||||
|
||||
The environment is not represented by one immutable version. The latest signed
|
||||
release artifact present is `1.0.0-rc1.15` at commit `a7bd086...`, while the live
|
||||
cluster contains later code/configuration overlays. Treat the verification date
|
||||
and the release artifact together as the baseline.
|
||||
|
||||
## 2. System context
|
||||
|
||||
Nexus One AI is an on-premises control and application plane for governed AI.
|
||||
Users enter through one TLS origin, authenticate through Keycloak, and receive
|
||||
role-filtered access to AI workspaces, enterprise knowledge, documents,
|
||||
automation, App Studio and administration. Durable state is held in PostgreSQL,
|
||||
large artifacts in MinIO, and background jobs are transported through RabbitMQ.
|
||||
AI execution is accessed through a replaceable OpenAI-compatible inference
|
||||
provider and is not required for basic control-plane availability.
|
||||
|
||||
```text
|
||||
Users and administrators
|
||||
|
|
||||
v
|
||||
Traefik TLS ingress - nexus-dev.cezen.lan
|
||||
|
|
||||
+--> Keycloak OIDC / role authorization
|
||||
|
|
||||
+--> Nexus Portal
|
||||
| +--> AI Workspace / Open WebUI
|
||||
| +--> Notebook / documents / datasets / evaluations
|
||||
| +--> agents / workflows / schedules / meetings
|
||||
| +--> App Studio / applications / templates
|
||||
| +--> administration / audit / health / packs
|
||||
|
|
||||
+--> Core API <--> PostgreSQL + pgvector
|
||||
| |
|
||||
| +--> RabbitMQ --> Scheduler / Worker
|
||||
| +--> MinIO governed artifacts
|
||||
| +--> model gateway --> replaceable inference provider
|
||||
|
|
||||
+--> App Gateway --> isolated application previews/releases
|
||||
+--> JupyterHub --> persistent developer workspaces
|
||||
|
||||
Platform telemetry --> Prometheus / Alertmanager / Grafana
|
||||
Platform logs --> Alloy / Loki / Grafana
|
||||
Recovery --> scheduled backup evidence and restore verification
|
||||
```
|
||||
|
||||
## 3. Live deployment topology
|
||||
|
||||
The reference appliance is a single K3s control-plane node running Ubuntu
|
||||
22.04.5. K3s provides DNS, local-path storage, metrics and Traefik. Product
|
||||
workloads are separated into platform, data, observability, workspace and
|
||||
application-preview namespaces.
|
||||
|
||||
### Platform namespace
|
||||
|
||||
- Two Core API replicas provide the protected product API.
|
||||
- Two portal replicas serve the dependency-light web interface.
|
||||
- Two App Gateway replicas route approved applications and previews.
|
||||
- Keycloak provides OIDC identity and role claims.
|
||||
- Job Scheduler and Job Worker execute durable background work.
|
||||
- Open WebUI provides the approved conversational workspace behind SSO.
|
||||
- Admin Extension provides controlled administrative capabilities.
|
||||
- Document Renderer and Document Scanner isolate document processing.
|
||||
|
||||
### Data namespace
|
||||
|
||||
- PostgreSQL 17 with pgvector is authoritative for product, job, workflow,
|
||||
application and audit state, and supports vector retrieval.
|
||||
- RabbitMQ transports durable work references; it is not authoritative state.
|
||||
- MinIO stores large governed objects, outputs and artifacts.
|
||||
|
||||
### Workspace and preview namespaces
|
||||
|
||||
- JupyterHub provides authenticated, persistent developer workspaces.
|
||||
- App Studio creates isolated preview Deployments, Services and ConfigMaps.
|
||||
- Approved applications are exposed through the App Gateway; preview resources
|
||||
can be stopped and removed without changing the authoritative project history.
|
||||
|
||||
### Observability namespace
|
||||
|
||||
- Prometheus collects Kubernetes, service, host, PostgreSQL and GPU metrics.
|
||||
- Alertmanager applies warning/critical response policy.
|
||||
- Grafana provides platform, capacity, inference, GPU and database dashboards.
|
||||
- Alloy and Loki collect and retain logs.
|
||||
|
||||
## 4. Identity, roles and access boundaries
|
||||
|
||||
Keycloak is the central identity provider. Portal navigation and APIs apply
|
||||
roles for application users, developers, reviewers, auditors, operators, pack
|
||||
managers and platform administrators. Reviewer and read-only roles are treated
|
||||
restrictively unless an explicit operational or administrative role is also
|
||||
present.
|
||||
|
||||
The browser never receives connector secrets. Connector and meeting-provider
|
||||
records carry server-side secret references, allowlisted hosts, bounded scopes,
|
||||
retention terms and activation state. Generated applications and packs are
|
||||
isolated and require explicit acceptance before broader availability.
|
||||
|
||||
## 5. AI Workspace and prompt management
|
||||
|
||||
### AI Workspace
|
||||
|
||||
Open WebUI is integrated behind Nexus SSO for persistent conversations, local
|
||||
or approved models and file-assisted chat. The logical `nexus-default` model
|
||||
decouples applications from a specific provider. General chat output is not
|
||||
treated as governed source evidence; cited work belongs in Nexus Notebook.
|
||||
|
||||
### Prompt Studio and Library
|
||||
|
||||
The prompt platform stores private/shared, versioned prompt assets. Prompt
|
||||
Studio supports variables, expert personas, structured instructions, local
|
||||
inference runs and hand-off into evaluation. The live interface includes
|
||||
business, data, legal, security, content and product-management expert modes.
|
||||
|
||||
### Evaluation and feedback
|
||||
|
||||
Evaluation suites run repeatable cases against selected models and persist
|
||||
quality/safety evidence. The quality area also groups model comparison, RAG
|
||||
quality and reviewed user feedback. Results are evidence for model/prompt
|
||||
selection, not a universal certification of a model.
|
||||
|
||||
## 6. Nexus Notebook and document intelligence
|
||||
|
||||
### Knowledge workflow
|
||||
|
||||
Collections are private by default and may be shared through controlled access.
|
||||
Sources are uploaded, extracted and indexed. Questions retrieve approved source
|
||||
segments, generate an answer and preserve citations. Conversations, source
|
||||
panels, generated outputs, exports, access management and audit links form one
|
||||
governed workspace.
|
||||
|
||||
### Document processing flow
|
||||
|
||||
```text
|
||||
Upload -> malware/type/size policy -> isolated extraction/OCR -> review
|
||||
-> metadata and chunks -> PostgreSQL/pgvector + object storage
|
||||
-> retrieval/reranking -> model generation -> cited answer/output
|
||||
```
|
||||
|
||||
### Document Compare
|
||||
|
||||
The current Enterprise Pilot supports durable comparisons for text and Office
|
||||
formats, including TXT, Markdown, CSV, JSON, PDF, DOCX, XLSX and PPTX. Jobs
|
||||
persist the comparison, support export, and can generate a grounded AI brief.
|
||||
|
||||
### Document Digitization
|
||||
|
||||
The digitization path performs local OCR, assisted field extraction, human
|
||||
validation, persistence and Notebook publication. It includes Indian GST, PAN
|
||||
and tender-oriented assistance. On the evidence date, one newer scanner pod was
|
||||
crash-looping while an older scanner pod was ready; this service is therefore
|
||||
degraded pending rollout reconciliation.
|
||||
|
||||
### Dataset creation and training
|
||||
|
||||
Datasets can be generated from PDF, DOCX, TXT, Markdown and CSV, reviewed row by
|
||||
row, and published as immutable versions with lineage/checksum evidence.
|
||||
Training requests support governed LoRA/full/embedding choices, but execution is
|
||||
gated by signed runtime prerequisites and compatible accelerator capacity.
|
||||
|
||||
## 7. Automation and collaboration
|
||||
|
||||
Agents define multistep model/tool behavior under approved capabilities.
|
||||
Workflows connect AI, retrieval, transformation and integration steps.
|
||||
Schedulers and workers execute manual or timed runs and retain their history.
|
||||
Human review can be placed at consequential boundaries.
|
||||
|
||||
Meeting Assistant uses a provider-neutral record and post-meeting evidence
|
||||
pipeline. Microsoft Teams, Zoom and Zoho Meeting are provision-only until a
|
||||
customer approves tenant permissions, consent, retention, secret and regional
|
||||
data-boundary requirements. Chat Rooms provide membership-controlled human and
|
||||
AI collaboration with optional Notebook grounding.
|
||||
|
||||
## 8. Application and extension platform
|
||||
|
||||
App Studio turns requirements into governed projects with persistent workspaces,
|
||||
proposals and source history. Code runs in isolated Kubernetes sandboxes.
|
||||
Preview, review, independent approval, publish, versioning, rollback and cleanup
|
||||
are separate lifecycle stages.
|
||||
|
||||
The Pack Manager imports signed offline capability packs and validates identity,
|
||||
signature, policy, vulnerabilities and embedded-secret constraints. Accepted
|
||||
packs can be enabled, upgraded, disabled, rolled back or removed. Python and
|
||||
TypeScript SDKs, templates and an offline conformance suite support controlled
|
||||
extensions.
|
||||
|
||||
## 9. Security and governance controls
|
||||
|
||||
Current controls include:
|
||||
|
||||
- encrypted K3s Secret storage and protected host-file permissions;
|
||||
- digest-pinned running core images;
|
||||
- checks against host access and privileged workload execution;
|
||||
- Keycloak OIDC, role enforcement and unified sessions;
|
||||
- append-only audit ownership and administrative activity evidence;
|
||||
- API credential governance and inference guardrails;
|
||||
- signed release/pack inventories and fail-closed validation;
|
||||
- server-side connector secrets, host allowlists and bounded capabilities;
|
||||
- certificate-expiry monitoring;
|
||||
- support-bundle redaction and recurring compliance evidence.
|
||||
|
||||
The 1 September security record passed all recorded controls, including secret
|
||||
encryption, file modes, certificate life, workload privilege, pinned images and
|
||||
audit ownership. This is environment evidence, not an external certification.
|
||||
|
||||
## 10. Operations, resilience and service objectives
|
||||
|
||||
The platform publishes health, resource, inference, GPU, database, logs and job
|
||||
evidence. Operational objectives for the single-node pilot include 99.5% portal
|
||||
readiness, 95% of inference responses below 30 seconds, GPU telemetry presence,
|
||||
VRAM warning at 90%, critical at 97%, backup age below 30 hours, and successful
|
||||
daily restore verification. These are internal objectives, not contractual SLAs.
|
||||
|
||||
The latest inspected evidence showed:
|
||||
|
||||
- daily enterprise readiness: pass;
|
||||
- security compliance: pass;
|
||||
- backup evidence: pass;
|
||||
- 32 retained backups;
|
||||
- latest backup 2.52 hours old;
|
||||
- 28.68% backup-storage headroom;
|
||||
- portal, Core API and Open WebUI ingress probes: HTTP 200.
|
||||
|
||||
## 11. Release and air-gapped delivery
|
||||
|
||||
Signed offline release bundles and a bootable AMD64 pilot ISO exist. The release
|
||||
model uses digest-pinned images, source/component inventories, signed packs and
|
||||
controlled upgrade/rollback contracts. The current pilot is still provisional:
|
||||
the live overlay state must be frozen, reviewed and rebuilt into current signed
|
||||
media before production promotion.
|
||||
|
||||
## 12. Known limitations and release gaps
|
||||
|
||||
1. The environment is a single-node pilot and does not prove high availability.
|
||||
2. One document-scanner rollout replica is unhealthy.
|
||||
3. Independent encrypted off-host backup and replacement-host restore are not yet proven.
|
||||
4. Prior-supported-release upgrade, migration compatibility and rollback remain open.
|
||||
5. Customer production PKI and directory federation require site validation.
|
||||
6. External connectors and meeting providers require customer provisioning.
|
||||
7. Model throughput, concurrency and quality have not been certified across commercial hardware tiers.
|
||||
8. The current signed media predates some accepted live overlays.
|
||||
9. Gate 10 remains provisional and Gate 11 clean-machine installation has not started.
|
||||
|
||||
## 13. Recommended documentation and engineering next steps
|
||||
|
||||
1. Repair and qualify the document-scanner rollout.
|
||||
2. Create a single build manifest linking source commit, overlay versions, image digests and migration level.
|
||||
3. Freeze live changes and rebuild signed offline media.
|
||||
4. Complete clean-machine, disconnected installation and upgrade/rollback acceptance.
|
||||
5. Establish model/hardware performance matrices with explicit assumptions.
|
||||
6. Prove off-host recovery and record RPO/RTO evidence.
|
||||
7. Produce customer profiles for PKI, AD/LDAP, inference, storage and approved connectors.
|
||||
8. Maintain this reference automatically from cluster inventory and acceptance evidence.
|
||||
|
||||
## 14. Evidence sources
|
||||
|
||||
- Live K3s node, namespace, workload, Service and Ingress inventory from `.155`.
|
||||
- Live portal navigation and runtime source under `/srv/nexus/source/nexus-platform`.
|
||||
- Signed release artifacts under `/srv/nexus/artifacts/releases`.
|
||||
- Enterprise Pilot build status and README from release source `rc1.15-a7bd086`.
|
||||
- Readiness evidence generated 31 August 2026 06:06 UTC.
|
||||
- Security evidence generated 1 September 2026 00:00 UTC.
|
||||
- Backup evidence generated 1 September 2026 04:55 UTC.
|
||||
- Direct canonical-ingress probes for portal, Core API and Open WebUI.
|
||||
|
||||
Reference in new issue
Block a user