Files
aipackage/autoinstall/offline
..

Nexus One AI Offline Workstation Payload

This directory contains Gate 2 Offline Workstation payload-resolution and disposable-validation tools. It does not currently contain a lock-driven bundle assembler or build-iso-offline.sh. No command in this directory produces a release ISO, and the existing mutable body in build-bundle.sh is deliberately unreachable.

The agreed bootable release matrix is:

  1. Online Universal Server ISO with Server S/M/L/Max selection.
  2. Offline Workstation ISO.
  3. Offline Server S/M ISO.
  4. Offline Server L/Max ISO.

Large models remain separate signed model packs. Signed update bundles patch installed appliances without an operating-system reinstall, and validated updates are periodically rolled into refreshed ISO builds.

Offline Workstation contents

  • the exact aipackage source revision used for the build
  • Ubuntu, Docker, NVIDIA and appliance .deb packages
  • Python wheels for the backend, RAG, ChromaDB and optional JupyterLab
  • Miniconda installer and an offline Python 3.11 environment package
  • Ollama runtime with phi3:mini and nomic-embed-text
  • vLLM and web/monitoring container images
  • the pinned Phi-3 Hugging Face model snapshot used by vLLM
  • K3s, MinIO and mc binaries for update/model packs (not enabled by Starter)
  • SHA-256 manifests and build provenance

Server L/Max models are intentionally separate signed model packs. Optional external connectors cannot operate without a customer-approved route to their target.

Current operator flow

The only authorized/current flow is:

  1. Resolve candidate inventory on a connected, isolated staging host.
  2. Review candidate object identity, bytes, origin, license and unresolved entries.
  3. Validate the candidate lock; it MUST fail while status is not reviewed or unresolved entries exist.
  4. Exercise signed-profile, checkpoint, install and rollback components only against disposable targets.
  5. Stop. Assembly, ISO injection, signing and release validation are not implemented.
Stage Tool Current status
Source/OCI candidate resolution resolve-payload-lock.py Evidence-only; OCI archive bytes/licenses remain open
Clean APT closure resolve-apt-lock.py Evidence-only; repository snapshot/origin/licenses and NVIDIA APT closure remain open
Backend/Chroma/platform wheel closures resolve-python-lock.py Evidence-only; three independent environments, candidate lock only
Whole-lock preflight validate-payload-lock.py Available and fail-closed
CPU/NVIDIA profile bytes validate-python-runtime-profile.py Available for exact candidate directories
Signed membership verify-python-profile-membership.py Implemented/test-key proven; production trust inputs absent
Selection planning plan-python-runtime-profile.py Non-mutating; production receipt required by default
Atomic journal/checkpoint preparation prepare-python-profile-operation.py Disposable/pre-mutation evidence only
Offline Python mutation/rollback install-python-profile.py Disposable targets only; not installer-wired
Bundle assembly build-bundle.sh Hard blocked after lock validation; legacy body unreachable
Offline ISO build autoinstall/build-iso-offline.sh Absent; C1 readiness blocker

Candidate resolution stages

  1. Resolve payload-lock.candidate.json into a reviewed payload-lock.json containing every object version, architecture, source, target, byte size, SHA-256 and license. The candidate intentionally fails validation while any entry is unresolved. The first connected resolution stage is: python3 autoinstall/offline/resolve-payload-lock.py --candidate autoinstall/offline/payload-lock.candidate.json --source-root . --container-sources autoinstall/offline/container-sources.json --staging <gate2-staging> --output <candidate-lock>. It creates a deterministic source archive and resolves the Linux/AMD64 OCI manifests without pulling image layers. Registry-declared bytes are not final measured payload bytes. Resolve the Ubuntu package closure from an empty package state with python3 autoinstall/offline/resolve-apt-lock.py --lock <candidate-lock> --packages autoinstall/offline/apt-packages.txt --work <apt-staging> --output <next-candidate-lock>. The result records exact .deb bytes but remains unresolved until repository snapshot/origin, license/notice, and the separate NVIDIA R570/CUDA 12.8.1 closure are approved. Resolve the three independent Python 3.11 wheel closures with python3 autoinstall/offline/resolve-python-lock.py --lock <candidate-lock> --backend-requirements ansible/roles/cezen-backend/files/requirements.txt --platform-requirements autoinstall/offline/python-packages.txt --work <python-staging> --output <next-candidate-lock>. The resolver pins its own pip version, accepts binary wheels only, and hashes every wheel. Index provenance, licenses, offline install/import and CUDA compatibility remain review gates.
  2. Run python3 autoinstall/offline/validate-payload-lock.py autoinstall/offline/payload-lock.json. No acquisition or output deletion occurs before this passes.
  3. Do not run build-bundle.sh expecting output. It validates the lock and then stops because lock-driven acquisition is not implemented. It will not fall back to the legacy mutable path.

Disposable profile evidence

  • python-runtime-profiles.json defines exactly-one cpu-only or nvidia-cu128 selection.
  • verify-python-profile-membership.py emits the closed receipt consumed by the planner; structural test receipts require an explicit test-only switch and are rejected in production mode.
  • prepare-python-profile-operation.py validates membership and wheel bytes, writes the atomic journal, creates/verifies the checkpoint and stops at checkpoint_ready without mutation.
  • install-python-profile.py installs from a selected local wheel directory with --no-index, performs health checks, atomically activates, and supports checkpoint rollback. It is currently authorized only for disposable evidence paths.

Mandatory stop conditions

Stop without assembly or mutation when any of the following is true: lock status is not reviewed, unresolved entries remain, a required object/hash/profile membership is missing, signature/trust policy is unverified, the journal/checkpoint is invalid, the selected hardware profile is unsupported, or the target is not an explicitly disposable evidence path.

An ISO must not be labelled offline merely because source or candidate payload bytes were embedded. Only a future signed, lock-driven artifact that passes the full disconnected acceptance matrix may use the Offline Workstation release label.