aipackage/docs/NEXUS_ONE_AI_LIVE_TECHNICAL_REFERENCE_155.md

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.

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

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.