aipackage/specs/001-enterprise-experience/spec.md

Feature Specification: Enterprise Appliance Experience Hardening

Feature Branch: main

Created: 2026-07-12

Status: Draft

Input: User description: "Make Nexus One AI a top-notch customer experience that feels like an enterprise appliance."

Clarifications

Session 2026-07-12

• Q: Should enterprise-experience hardening ship as phases or as one complete redesign? → A: Phased rollout: setup/readiness first, daily administration second, recovery/support third.
• Q: Which product configurations must Phase 1 cover? → A: One representative Workstation and one representative Server configuration.
• Q: How should each phase progress to general release? → A: Internal validation, then a controlled customer pilot, then general release.
• Q: Who approves completion of each phase? → A: Product owner and delivery/support jointly approve.
• Q: What accessibility standard applies to customer-facing setup and portal experiences? → A: WCAG 2.2 Level AA.

User Scenarios & Testing (mandatory)

User Story 1 - Confident First-Time Setup (Priority: P1)

As a customer administrator, I can move from first boot through a validated, ready-to-use Nexus One AI appliance without needing undocumented knowledge or encountering contradictory product, tier, or license information.

Why this priority: Installation is the customer's first direct experience of the product and a failed or ambiguous setup prevents every later outcome.

Independent Test: A representative administrator can complete setup on a supported appliance, understand every decision, recover from correctable input or service failures, and reach a clearly identified ready state using only product-provided guidance.

Acceptance Scenarios:

1. Given a supported new appliance, When the administrator completes setup with valid inputs, Then each step explains its purpose, validates before commitment, preserves previous choices, and ends with an accurate readiness summary and next actions.
2. Given invalid network, customer, license, tier, or component input, When validation fails, Then the administrator sees a plain-language explanation beside the affected decision and can correct it without restarting the entire journey.
3. Given installation is interrupted or a required component fails, When the administrator returns to the appliance, Then the product shows the last reliable state, customer impact, diagnostic reference, and safe resume or recovery action.
4. Given hardware or licensing prevents a tier or component selection, When options are shown, Then unavailable choices are explained using customer-facing product names and no unsupported configuration can be committed accidentally.

---

User Story 2 - Coherent Daily Administration (Priority: P1)

As an authorized administrator, I can understand appliance health, capacity, licensing, security, users, models, knowledge, and operational work from one coherent product experience.

Why this priority: Daily confidence depends on the portal behaving as a unified control plane, not a collection of disconnected pages and tools.

Independent Test: An administrator can identify overall appliance state, locate the five most common administrative tasks, complete each task, and interpret success or failure without external guidance.

Acceptance Scenarios:

1. Given a healthy appliance, When the administrator signs in, Then the landing experience presents current readiness, important alerts, capacity context, license/support state, and the highest-value next actions without fabricated or stale status.
2. Given the administrator moves between portal areas, When equivalent concepts or actions appear, Then naming, navigation, status severity, interaction, and confirmation patterns remain consistent.
3. Given an operation is long-running, When it starts, progresses, completes, or fails, Then its state remains discoverable and the administrator is not left uncertain whether the action occurred.
4. Given an empty, loading, restricted, partially available, or failed state, When a page is viewed, Then the state is distinguishable, truthful, and accompanied by an appropriate action.

---

User Story 3 - Safe Operations and Recovery (Priority: P1)

As an appliance operator or support engineer, I can diagnose and recover common operational problems without exposing secrets, damaging customer data, or relying on source-code knowledge.

Why this priority: Enterprise trust is established during failure and recovery, not only during normal operation.

Independent Test: A trained operator can use product-provided health, audit, diagnostic, backup, and recovery guidance to resolve or escalate representative failures with a complete evidence trail.

Acceptance Scenarios:

1. Given one or more services are degraded, When the operator reviews system status, Then the product distinguishes customer impact from technical detail and identifies safe checks, recovery actions, and escalation evidence.
2. Given a backup, restore, upgrade, restart, or other consequential action, When it is requested, Then prerequisites, scope, expected disruption, confirmation, progress, result, and rollback or recovery guidance are available.
3. Given diagnostics are generated, When they are viewed or exported, Then secrets and protected customer content are excluded while timestamps, correlation details, and relevant state remain sufficient for support.
4. Given a privileged or security-sensitive action occurs, When audit history is reviewed, Then it identifies who acted, what category of change occurred, when it occurred, the result, and the affected scope without recording secret values.
5. Given an authorized administrator needs to remove appliance software, When removal is requested, Then retained and deleted data, service impact, prerequisites, confirmation, progress, result, rollback limits, and recovery or escalation guidance are explicit.

---

User Story 4 - Predictable Product Entitlements (Priority: P2)

As a customer or Cezen delivery team member, I see capabilities that accurately match the purchased Nexus One AI product, licensed tier, provisioned components, and supported hardware.

Why this priority: Contradictions between sales labels, licenses, installation options, portal capabilities, and documentation undermine confidence and create field-support failures.

Independent Test: Representative Workstation and Server S/M/L/Max configurations show the correct labels, permitted actions, explanatory restrictions, and matching documentation throughout setup and daily administration.

Acceptance Scenarios:

1. Given any supported product and tier, When product identity or entitlement is displayed, Then customer-facing labels are consistent while internal compatibility identifiers remain hidden unless diagnostically necessary.
2. Given a capability is not licensed, provisioned, supported by hardware, or currently available, When the customer encounters it, Then the product distinguishes those causes and provides the appropriate commercial, provisioning, hardware, or recovery next action.
3. Given a package or release is prepared, When its customer experience is accepted, Then installer, portal, backend behaviour, deployment roles, documentation, and delivery artifact agree on product names and capability boundaries.

---

User Story 5 - Guided Evaluation and Handover (Priority: P2)

As a customer evaluator or newly assigned administrator, I can understand what the appliance is, verify that it is ready, discover its key capabilities, and find authoritative help without a live Cezen walkthrough.

Why this priority: A polished enterprise product must remain understandable after the sales or delivery team leaves.

Independent Test: A representative evaluator can identify product purpose, current readiness, licensed capabilities, key first tasks, help resources, and support evidence within ten minutes.

Acceptance Scenarios:

1. Given a newly provisioned appliance, When an evaluator first enters the portal, Then the experience provides role-appropriate orientation without blocking experienced users.
2. Given a user needs help, When contextual and central help are accessed, Then guidance matches the current product terminology and points to safe, relevant actions.
3. Given the appliance is operating in a restricted network, When help or diagnostics are needed, Then essential guidance remains locally available and external dependencies are clearly identified.

Edge Cases

• Browser refresh, session expiry, duplicate submission, or navigation during a long-running action.
• Power, network, storage, GPU, or dependent-service loss during setup or maintenance.
• License missing, malformed, expired, hardware-bound incorrectly, or valid for a different tier.
• Appliance provisioned above or below current license or hardware capability.
• Partial installation where some tools are intentionally omitted and others failed unexpectedly.
• Empty system, first user, no models, no documents, no audit events, and no historical health data.
• Multiple simultaneous administrators attempting conflicting consequential operations.
• Clock drift or unavailable time source affecting licenses, certificates, logs, and audit ordering.
• Insufficient storage or capacity discovered before and during a consequential operation.
• Diagnostic export requested when protected customer documents or secrets are present.
• Upgrade or restart interrupted after state changes but before completion is recorded.
• Removal interrupted after services or data have been changed but before completion is recorded.
• Portal information is temporarily older than the underlying appliance state.

Requirements (mandatory)

Functional Requirements

• FR-001: The product MUST provide a continuous, understandable journey from first boot to a verified ready state.
• FR-002: The product MUST present a unified view of overall readiness, degraded conditions, important alerts, capacity context, license/support state, and actionable next steps.
• FR-003: Every customer-facing status MUST distinguish at least loading, empty, ready, degraded, failed, restricted, and unavailable states when those states are possible.
• FR-004: Every customer-correctable error MUST explain the problem, affected scope, and safe next action without exposing implementation-only codes as the primary message.
• FR-005: Long-running and consequential operations MUST expose initiation, progress, completion, failure, and recovery state that remains discoverable after navigation or session interruption.
• FR-006: Consequential operations MUST identify prerequisites, scope, expected disruption, and recovery implications before confirmation.
• FR-007: The product MUST prevent accidental duplicate or conflicting consequential operations.
• FR-008: Navigation, product terminology, severity levels, interaction patterns, confirmations, and feedback MUST be consistent across customer-facing areas.
• FR-009: Customer-visible operational values MUST identify their freshness or last-observed time when they are not guaranteed to be live.
• FR-010: The product MUST provide contextual help for setup, licensing, health, models, knowledge, users, security, backup, restore, upgrade, and recovery journeys.
• FR-011: Essential setup, operational, recovery, and escalation guidance MUST remain available on the appliance without requiring public internet access.
• FR-012: Role restrictions MUST be explained without revealing protected data or presenting controls that appear usable but always fail.
• FR-013: Privileged, security-sensitive, licensing, configuration, and lifecycle actions MUST create an audit record containing actor, time, action category, affected scope, and outcome.
• FR-014: Diagnostic views and exports MUST omit secrets, credentials, license payloads, and protected customer content by default.
• FR-015: Support evidence MUST include enough timestamps, correlation details, product identity, entitlement state, and component health to reproduce or escalate a reported issue.
• FR-016: The product MUST accurately distinguish licensed, provisioned, hardware-supported, and currently available capability states.
• FR-017: Workstation and Server S/M/L/Max naming and capabilities MUST remain consistent across setup, portal, documentation, support evidence, and release artifacts.
• FR-018: The product MUST provide a concise first-use orientation and a persistent route to authoritative help without obstructing returning users.
• FR-019: Every release affecting customer journeys MUST identify all changed surfaces and verify that the packaged delivery contains the accepted versions.
• FR-020: Known degraded capabilities MUST be visible to affected users and MUST NOT be represented as healthy or complete.
• FR-021: The product MUST preserve customer-entered setup data and completed safe steps when a recoverable interruption occurs.
• FR-022: Recovery actions MUST clearly distinguish safe retry, resume, rollback, restore, restart, and escalation choices when applicable.
• FR-023: Delivery MUST use three independently accepted phases in this order: setup and readiness, daily administration, then recovery and support. Each phase MUST satisfy its applicable quality gates before the next phase is accepted.
• FR-024: Phase 1 acceptance MUST include one representative Workstation configuration and one representative Server configuration; shared behaviour MUST pass on both, while tier-specific behaviour MUST be explicitly identified for later matrix coverage.
• FR-025: Each phase MUST pass internal validation and a controlled customer pilot before general release. Pilot findings that affect customer safety, task completion, entitlement accuracy, or recovery MUST be resolved and revalidated before promotion.
• FR-026: Phase acceptance MUST require recorded joint approval from the product owner and an accountable delivery/support representative after reviewing customer-experience and operational evidence.
• FR-027: Customer-facing setup and portal journeys MUST conform to WCAG 2.2 Level AA, including keyboard operation, focus visibility, semantic structure, accessible names, contrast, status announcements, error identification, and non-colour status cues.
• FR-028: Appliance software removal MUST be an authorized, auditable, durable operation that identifies retained and deleted data, requires explicit confirmation, protects backups by default, and provides truthful completion, rollback-limit, recovery, and escalation outcomes.
• FR-029: Every new operation, recovery, removal, diagnostic, and support-evidence interface MUST enforce server-side authorization and MUST be covered by allowed-role and denied-role tests.
• FR-030: Release packaging MUST use exactly four bootable products: Online Universal Server, Offline Workstation, Offline Server S/M, and Offline Server L/Max. Workstation MUST NOT appear in the Server tier selector, and no offline Server image may select a tier outside its named pair.
• FR-031: Offline Workstation is the first offline implementation target. Offline Server S/M and Offline Server L/Max remain blocked until the shared offline contract passes on Workstation.
• FR-032: An artifact MUST NOT be described as offline unless a clean target, with every network interface disabled or physically disconnected from boot until acceptance completes, installs and reaches its declared ready or explicitly degraded state without DNS, routing, mirrors, registries, repositories, license servers, time services, telemetry, or other network responses.
• FR-033: Each offline ISO MUST contain the Ubuntu boot/install base, installer logic, the exact platform revision, all packages/runtimes/images required by its category and selectable tiers, local help, trust roots, manifests, and only the approved starter-model set. Optional connectors MAY be installed but MUST be reported unavailable, not failed or ready, when their remote targets are unreachable.
• FR-034: Large models MUST be distributed as separately signed model packs and MUST NOT be duplicated in bootable media. A model pack MUST declare compatible product categories, tiers, platform versions, hardware/storage prerequisites, content identity, and installed-state effect.
• FR-035: All installed products MUST accept one shared signed offline-update bundle format. Bundles MUST declare source and target platform versions, compatible categories/tiers, ordered actions, space and service-impact prerequisites, payload digests, and rollback classification.
• FR-036: ISO payloads, model packs, and update bundles MUST use a versioned manifest, a digest for every payload object, a detached release signature, an identified signing key, and an offline trust/revocation policy. Verification MUST fail closed before any target mutation.
• FR-037: Update and import operations MUST stage and verify before activation, preserve the last known-good state or a documented pre-change backup, commit atomically where supported, and report whether rollback is automatic, operator-invoked, restore-based, or impossible before confirmation.
• FR-038: Interrupted boot, install, first boot, payload verification, model import, update staging, activation, reboot, and rollback MUST each have a deterministic outcome: safe resume, safe restart, automatic rollback, operator recovery, or a non-destructive blocked state with evidence.
• FR-039: Published media guidance MUST be derived from measured release artifacts. Required media capacity is the smallest common capacity with at least 20% headroom above the finalized artifact and any flashing overhead; estimates MUST be labelled estimates and Server offline sizes MUST not be published before payload build and deduplication evidence exists.
• FR-040: No installer product may advance from planned to implementation-ready, release candidate, or generally releasable without the evidence gates defined in the installer artifact contract.
• FR-041: Offline Workstation media MUST be universal and hardware-adaptive within its CPU architecture. GPU vendor model or VRAM class MUST NOT create separate Workstation products, media, or commercial tiers. Hardware detection MUST select safe local capability profiles and truthfully disable unsupported model/runtime functions while preserving the supported core platform.
• FR-042: CPU architecture is an artifact compatibility boundary. An AMD64 Workstation ISO MUST NOT claim ARM64 DGX Spark support; any ARM64 or proven multi-architecture media requires its own build identity and complete artifact evidence while remaining the same Workstation product category.
• FR-043: The first Offline Workstation release MUST support NVIDIA acceleration and truthful CPU-only fallback on approved AMD64 hosts. AMD GPU acceleration, ROCm, and Strix Halo acceleration are outside the first release and MUST NOT be advertised as supported merely because the ISO boots on an AMD64 CPU.
• FR-044: An update MUST NOT claim complete rollback based only on a customer-data backup. The rollback checkpoint MUST cover every affected application, configuration, service, runtime, container, schema, model, trust, driver, kernel, and OS surface or explicitly classify the update as restore-based/recovery-required before authorization.
• FR-045: Offline license activation MUST fail closed for invalid signature, unsupported policy, untrusted time, expiry, revocation, category/tier mismatch, unavailable or mismatched required machine binding, and MUST NOT treat a compatibility default as purchased entitlement.
• FR-046: Field staging MUST be an explicit restricted capability allowlist, not a free Server tier or fallback for invalid license material. License expiry/revocation/replacement MUST preserve customer data, backup/export, diagnostics and safe recovery according to approved policy.
• FR-047: Every release artifact MUST have a complete immutable object inventory with architecture, license, exact byte sizes and digests before assembly. Media and target-storage guidance MUST be calculated from built evidence; a placeholder, sparse or zero-byte ISO is not a release artifact.
• FR-048: Shared payload objects MUST be deduplicated by exact digest within an artifact. Separate Server L/Max media MUST have an approved support, validation or payload distinction after large models are excluded; tier naming alone is insufficient justification for duplicated boot media.
• FR-049: Offline acceptance MUST use an instrumented no-route capture segment plus physical-air-gap confirmation, classify every non-loopback attempt, and fail for any attempted external dependency fetch even when no response is received or a local fallback later succeeds.
• FR-050: Release evidence MUST identify executor and independent reviewer, preserve failed runs, distinguish invalid lab runs from product failures, and prohibit manual target repair within an acceptance run.
• FR-051: Every artifact MUST use a canonical semantic version, product/type/architecture identity, SBOM, provenance attestation, signed channel mapping, support window and retention status. Mutable filenames, branches or tags MUST NOT define release identity or promotion.
• FR-052: Stable release promotion MUST preserve immutable artifact bytes, retain withdrawal and revocation history, and provide an evidenced successor/update/recovery path through the declared support lifecycle.
• FR-053: Model-pack import MUST use bounded non-executable quarantine, reject unsafe or undeclared archive content, and publish a fully verified runtime view atomically. Shared content MUST be keyed and referenced by exact digest; interruption MUST leave the prior model set unchanged or recoverable.
• FR-054: Model-pack deactivation, uninstall and garbage collection MUST preserve dependencies, rollback/evidence holds and customer-created data, delete only zero-reference objects, and respond deterministically to entitlement, tier/category, redistribution-license and security-withdrawal changes without silently granting access or remotely deleting customer content.
• FR-055: Production release signing MUST use purpose-constrained keys in a release trust domain separate from license and test keys, dual-controlled offline root custody, independently approved digest-bound signing requests and immutable receipts. Rotation, expiry, revocation, monotonic offline trust updates and compromised-root recovery MUST fail closed for new activation without silently destroying customer data or recovery access.
• FR-056: Every release path MUST maintain an approved threat model from source and dependency intake through build, signing, distribution, installation, activation, recovery and evidence export. Security controls and tests MUST cover substitution, replay, unsafe archives, entitlement bypass, hidden network dependency, partial activation, rollback mismatch, reference deletion, evidence tampering, secret disclosure, insider role conflict, clock manipulation and architecture mismatch.

Enterprise Appliance Requirements (mandatory)

• EA-001 Customer Experience: All primary journeys and their empty, loading, restricted, degraded, failure, and recovery states MUST use consistent Nexus One AI language and actionable guidance.
• EA-002 Security & Audit: Authorization MUST be enforced for every privileged action; audit and diagnostics MUST retain useful evidence while excluding secret values and protected content.
• EA-003 Lifecycle & Recovery: Setup, configuration, restart, upgrade, backup, restore, and interruption behaviour MUST define safe preconditions, progress, outcomes, and recovery paths.
• EA-004 Entitlement & Packaging: Workstation and Server tier behaviour MUST remain consistent with licensed, provisioned, and hardware-supported capabilities across every delivery surface.
• EA-005 Operability: Health, diagnostics, logs, local help, and escalation evidence MUST support customer-controlled and restricted-network operation.

Key Entities

• Appliance Readiness: Overall customer-relevant state, affected capabilities, freshness, alerts, and next actions.
• Operation: A consequential or long-running activity with actor, scope, lifecycle state, progress, result, and recovery options.
• Entitlement State: Product category, commercial tier, licensed capabilities, provisioned components, hardware support, and current availability.
• Support Evidence Package: Redacted product identity, timestamps, correlation information, entitlement summary, health state, and relevant operational history.
• Audit Event: Actor, time, action category, affected scope, outcome, and correlation reference, excluding protected values.
• Guidance Item: Locally available contextual instructions associated with a journey, state, or recovery action.

Success Criteria (mandatory)

Measurable Outcomes

• SC-001: At least 90% of representative first-time administrators complete supported setup and reach a verified ready state without undocumented assistance.
• SC-002: At least 90% of representative administrators can identify overall appliance health, license state, and the correct next action for a degraded condition within two minutes.
• SC-003: At least 95% of customer-correctable failures tested provide an accurate explanation and a successful safe recovery path without restarting the entire journey.
• SC-004: The five most common administrative tasks can each be located within three navigation decisions and completed without external documentation by at least 90% of representative users.
• SC-005: 100% of tested privileged, security-sensitive, licensing, configuration, and lifecycle actions produce the required audit evidence without secret values.
• SC-006: 100% of representative Workstation and Server tier test cases display consistent product names and capability boundaries across setup, portal, help, and release acceptance evidence.
• SC-007: All tested consequential operations retain or recover a truthful final state after page refresh, session expiry, or simulated interruption.
• SC-008: A trained operator can diagnose, safely recover, or prepare a complete escalation package for each agreed common failure scenario within 15 minutes.
• SC-009: No accepted release contains placeholder content, dead controls, unexplained primary error codes, fabricated production values, or customer-visible legacy product naming.
• SC-010: Every accepted customer-facing release has traceable evidence for primary journeys, failure states, entitlement boundaries, recovery impact, and packaged artifact identity.
• SC-011: Phase 1 produces passing setup and readiness evidence on both one representative Workstation and one representative Server configuration.
• SC-012: Every general release has recorded internal-validation and controlled-pilot evidence, with no unresolved critical customer-safety, task-completion, entitlement, or recovery findings.
• SC-013: All customer-facing setup and portal pages changed by a phase pass automated checks and representative manual keyboard and assistive-technology checks for WCAG 2.2 Level AA conformance, with no unresolved Level A or Level AA failures at acceptance.
• SC-014: Under normal representative appliance conditions, readiness is displayed within 10 seconds of portal entry in at least 95% of measured trials.
• SC-015: Local navigation provides visible feedback within 1 second in at least 95% of measured interactions on supported browsers.
• SC-016: Consequential-operation submission provides acknowledgement or a validation result within 2 seconds in at least 95% of measured trials under normal appliance conditions.
• SC-017: Every accepted offline ISO completes three clean zero-network installations, including one reboot-boundary interruption run, with zero attempted dependency fetches and no undocumented intervention.
• SC-018: 100% of tampered, unsigned, expired-policy, revoked-key, incompatible-category/tier, and insufficient-space model/update artifacts are rejected before target mutation.
• SC-019: Every accepted interruption point produces the contractually declared recovery outcome and a complete operation/evidence record; no tested interruption leaves an ambiguous active state.
• SC-020: Every released ISO, model pack, and update bundle is reproducibly identified by product, version, source revision, manifest digest, signature identity, byte size, and whole-artifact digest.
• SC-021: The same AMD64 Offline Workstation ISO passes clean zero-network installation and truthful capability selection on representative CPU-only/sub-threshold, 8 GB, 24 GB, and 48 GB-or-higher NVIDIA GPU profiles without presenting any profile as a Server tier.
• SC-022: Every supported update path passes successful activation, power-loss interruption at each mutating boundary, declared automatic or restore-based rollback, and rollback-failure recovery with active application inventory and data/schema version in a consistent evidenced state.
• SC-023: 100% of offline license-state, clock, binding, revocation, staging, replacement and interruption cases produce the same entitlement decision across installer, backend, portal and evidence surfaces, with no unauthorized capability or raw license/binding secret exposed.
• SC-024: For every candidate ISO, signed inventory totals reconcile exactly with independently extracted media, and measured clean-install peak target/staging/rollback usage supports the published USB and disk minimum arithmetic with at least the required headroom.
• SC-025: Every accepted offline artifact completes at least three clean runs, including two physical targets and one declared interruption run, with classified packet evidence showing zero attempted external dependency fetches and independent review of the evidence index.
• SC-026: 100% of stable artifacts reconcile their inventory, canonical SBOM, provenance, signed manifest/channel index and published digest, and an independent rebuild has no unexplained trusted content difference.
• SC-027: 100% of model-pack import, shared-object, dependency, license-change, uninstall and garbage-collection acceptance cases finish with matching signed-pack inventory, reference graph, runtime-visible models, entitlement decision, disk usage and independently reviewed evidence.
• SC-028: 100% of signing acceptance cases reconcile approved input/output digests and receipts, while wrong-domain/purpose/namespace/channel, unknown, revoked, expired, future, stale-sequence, tampered, approval-mismatch and production-test-key cases are rejected with reviewed evidence.
• SC-029: Every threat-register case has an assigned control, deterministic expected safe state, linked automated or physical evidence and independent review; no artifact advances while a required control test fails or a residual risk lacks an accountable accepting owner.

Verification Evidence (mandatory)

• Static/local evidence: Terminology, navigation, state coverage, authorization, redaction, audit, entitlement, accessibility, and journey checks defined per affected surface.
• Deployment evidence: A clean supported installation plus upgrade or reconfiguration from a representative existing appliance, including interruption and recovery scenarios.
• Live-appliance evidence: Role-based setup and daily-administration journeys on representative Workstation and Server configurations, with healthy, empty, restricted, degraded, and failed states.
• Release artifact evidence: Recorded source revision, package identity, build time, checksum, and confirmation that accepted portal, service, deployment, help, and entitlement content is included.

Assumptions

• This feature hardens the existing Nexus One AI product rather than replacing its architecture.
• The first release targets current supported desktop browsers used on the customer network.
• Existing authentication, product categories, Server tier identifiers, licensing rules, and customer data remain authoritative unless a later specification explicitly changes them.
• The work includes the first-boot setup and customer portal plus the supporting operational behaviour necessary to make those journeys truthful.
• Delivery is phased: setup/readiness first, daily administration second, and recovery/support third; this ordering does not remove cross-phase consistency requirements.
• Public internet access cannot be assumed after installation.
• Exact capacity and performance thresholds will be set per product/tier during planning using validated hardware and workload evidence.
• The delivery team will identify the most common administrative tasks and failure scenarios from product telemetry where available, support history, and field experience before acceptance testing.
• Percentage-based administrator outcomes use at least 10 representative participants across internal validation and controlled pilot; results report the participant count and product configuration.
• The customer-correctable failure corpus contains at least 20 representative cases across input, entitlement, network, service, storage, interruption, and stale-state categories.
• Audit completeness is measured against a reviewed inventory of every privileged, security-sensitive, licensing, configuration, lifecycle, removal, and support-evidence action.
• Mobile-native applications, a complete visual rebrand, new commercial tiers, and replacement of underlying third-party tools are outside this feature unless separately specified.

Out of Scope

• Introducing new commercial product categories or changing purchased entitlement definitions.
• Replacing underlying AI, observability, notebook, or document-processing tools solely for visual consistency.
• Claiming high availability, redundancy, offline model availability, or recovery objectives that the deployed product has not been designed and validated to provide.
• Implementing feature changes during this specification phase.
• Embedding large optional models in any bootable ISO or creating tier-specific update formats.