# Nexus One AI Constitution ## Core Principles ### I. Enterprise Appliance Experience Every customer-facing journey MUST feel complete, coherent, and intentional across first boot, setup, login, administration, daily use, maintenance, and recovery. Screens MUST use consistent Nexus One AI naming, navigation, interaction patterns, and plain-language status messages. A customer MUST never encounter placeholder content, unexplained internal codes, dead controls, or demo-only behaviour in a release. Errors MUST state what happened, the customer impact, and a safe next action. Rationale: customers judge an appliance as one product, not as a collection of tools. ### II. Safe, Recoverable Lifecycle Installation, configuration, upgrade, backup, restore, and removal paths MUST be designed as recoverable lifecycle operations. Changes MUST preserve supported existing installations and data, or include an explicit migration and rollback path. Destructive operations MUST require clear confirmation and MUST identify their scope. Interrupted operations MUST either resume safely or provide documented recovery steps. Rationale: an enterprise appliance remains trustworthy when normal operations fail, not only when the happy path succeeds. ### III. Secure and Auditable by Default Secure defaults MUST apply without requiring customer expertise. Secrets, license material, credentials, and private customer data MUST never appear in source control, browser-visible logs, or routine diagnostics. Authentication and authorization MUST be enforced server-side. Privileged, security-sensitive, licensing, configuration, and lifecycle actions MUST produce useful audit records without leaking secrets. Security weakening for convenience requires explicit approval, documented risk, bounded scope, and a removal plan. Rationale: on-premises operation increases the need for predictable controls and supportable evidence. ### IV. Entitlement and Packaging Integrity Commercial product labels and internal compatibility identifiers MUST remain deliberately mapped. Nexus One AI Workstation MUST remain structurally separate from the Server tier ladder, and the existing `starter`, `basic`, `pro`, and `max` identifiers MUST remain compatible unless an approved migration covers every consumer. Portal, backend, license logic, Ansible roles, installer, packaged payload, documentation, and ISO delivery MUST agree on capabilities and naming. A delivery artifact MUST NOT be called current until its packaged source and build provenance are verified. Rationale: entitlement drift creates customer-visible failures that are difficult to repair in the field. ### V. Evidence-Based Quality No customer-facing feature is complete based only on code review or visual inspection. Each feature MUST define measurable acceptance criteria and MUST verify its primary journey, failure states, permissions, entitlement boundaries, and operational impact at the lowest sufficient test level. Changes spanning multiple surfaces MUST include end-to-end validation across those surfaces. Release claims MUST distinguish static checks, local tests, deployment tests, and live appliance validation. Known gaps MUST be documented rather than hidden. Rationale: enterprise quality is demonstrated by repeatable evidence. ## Product and Operational Constraints - Branding MUST use **Nexus One AI** with **Powered by Cezen** where company attribution is shown. - Workstation and Server S/M/L/Max capability differences MUST be explicit and testable. - Customer-visible values MUST come from real configuration or clearly labelled example data; they MUST NOT be fabricated as production state. - The platform MUST remain operable in customer-controlled and restricted-network environments; any internet dependency MUST be declared with an offline or controlled alternative where required. - Logs and diagnostics MUST be actionable for support while respecting secret and personal-data boundaries. - Performance, capacity, browser, hardware, and platform assumptions MUST be stated in each feature specification when they affect customer outcomes. ## Delivery Quality Gates 1. **Specify**: define user journeys, edge cases, measurable outcomes, support impact, and explicit exclusions before implementation planning. 2. **Clarify**: resolve decisions affecting security, data, licensing, recovery, compatibility, or customer-visible behaviour; unresolved decisions MUST NOT be silently guessed. 3. **Plan**: map every affected surface, migration, rollback, observability change, documentation update, and verification environment. 4. **Implement**: preserve unrelated behaviour, avoid unnecessary rewrites, and keep changes small enough to review and recover. 5. **Verify**: run the specified tests and capture evidence for the primary journey, failure paths, entitlement boundaries, upgrade/recovery impact, and packaged artifact when applicable. 6. **Release**: review the complete diff and release impact. Commit, push, deploy, rebuild an ISO, or change a live appliance only with explicit authorization for that action. Exceptions MUST identify the violated principle, customer or operational risk, mitigation, owner, and expiry condition. An exception without an expiry condition is invalid. ## Governance This constitution governs feature specifications, plans, tasks, implementation reviews, and release decisions for this repository. When another local convention conflicts with it, this constitution takes precedence unless a documented exception is approved. Amendments require a written rationale, impact review, corresponding template updates, and explicit project-owner approval. Versions follow semantic versioning: MAJOR for incompatible governance changes or principle removal, MINOR for new principles or materially expanded obligations, and PATCH for non-semantic clarification. Every feature plan MUST perform the Constitution Check before design and again after design. Every release review MUST record compliance or approved exceptions. **Version**: 1.0.0 | **Ratified**: 2026-07-12 | **Last Amended**: 2026-07-12