aipackage/specs/001-enterprise-experience/contracts/release-lifecycle-provenance.md

Release Naming, Provenance, Retention, and Support Lifecycle

Status: Approval draft; no release authority.

Artifact Identity

Artifact identity is independent of filename. The canonical identity tuple is artifact type, product, CPU architecture, release version, source revision, manifest digest, signing-key ID and whole-artifact digest. Two byte-different artifacts never share the same complete identity, even if filenames match.

Versioning

Nexus One AI platform releases use Semantic Versioning MAJOR.MINOR.PATCH:

• MAJOR: customer-impacting compatibility or migration boundary requiring explicit upgrade policy.
• MINOR: backward-compatible capability, supported hardware/profile or operational expansion.
• PATCH: backward-compatible defect/security fix without entitlement expansion.

Prerelease identifiers are dev.N, alpha.N, beta.N, rc.N and are never generally releasable. Build metadata MAY identify a reproducibility rerun but cannot distinguish customer-visible content; any payload change increments the release/prerelease version. Security floor and supported upgrade range use parsed semantic versions, never lexical comparison.

Models have their upstream immutable revision plus a Cezen pack revision, for example pack 1.0.0 containing a named upstream commit/manifest digest. Trust bundles have monotonically increasing policy versions and cannot be rolled back below the active signed floor.

Canonical Product and Filename Slugs

Artifact	Canonical artifact type/product slug	Filename pattern
Online Universal Server ISO	iso-online-server-universal	nexus-one-ai-online-server-universal_<version>_<arch>.iso
Offline Workstation ISO	iso-offline-workstation	nexus-one-ai-offline-workstation_<version>_<arch>.iso
Offline Server S/M ISO	iso-offline-server-sm	nexus-one-ai-offline-server-sm_<version>_<arch>.iso
Offline Server L/Max ISO	iso-offline-server-lmax	nexus-one-ai-offline-server-lmax_<version>_<arch>.iso
Model pack	model-pack-<model-slug>	nexus-one-ai-model-pack_<model-slug>_<upstream-revision>_<pack-version>_<arch>.tar.zst
Offline update	update-bundle	nexus-one-ai-update_<from-range>_to_<version>_<arch>.tar.zst
Trust bundle	trust-bundle	nexus-one-ai-trust_<policy-version>.json

Filenames use lowercase ASCII slugs, semantic versions, explicit architecture and no spaces. Filename is display/convenience metadata and is never trusted without signed-manifest verification.

Release Channels

Channel	Permitted artifacts	Promotion rule
development	Internal unsigned build outputs allowed only in isolated build/test systems	Never delivered to customers
internal	Signed prerelease	Static/schema/security tests and reproducible identity pass
pilot	Signed RC	Required physical/offline/update/recovery evidence plus pilot authorization
stable	Signed final	All gates, independent review and joint product/delivery approval pass
security	Signed targeted update/trust bundle	Security-owner scope plus product/delivery recovery approval

Promotion does not rename or mutate bytes. A promoted release is rebuilt under a new final version or the exact already-signed artifact is referenced by a new signed channel index according to approved policy; silent replacement is prohibited.

SBOM

Every ISO payload, model pack and update bundle includes:

• SPDX 3.0.1 JSON as the canonical release SBOM;
• package/file/component identities, versions, suppliers, licenses, checksums and relationships;
• OS packages, Python/Conda packages, container images/layers, binaries, source package, JavaScript assets, models/runtime objects and embedded build/install tools;
• generated timestamp and tool identity separated from reproducible component content;
• declared unknown/incomplete license fields as release blockers, not guessed values.

CycloneDX MAY be generated as an additional customer/tooling view but cannot replace canonical SPDX. Model SBOM entries include provider, model/revision, weight/config/tokenizer/template/license object digests and declared runtime relationship.

Provenance

Every built artifact carries an in-toto Attestation Framework v1.2 Statement v1 using the SLSA Provenance v1 predicate (aligned to the SLSA specification v1.2), encoded as canonical JSON and referenced by digest from the artifact manifest. It identifies:

• source repository and exact revision plus clean/dirty state;
• build recipe/revision, resolved immutable inputs and dependency/object digests;
• builder identity, isolated environment image/OS/tool versions and architecture;
• build start/end, invocation parameters excluding secrets, network policy and reproducibility status;
• output artifact/manifest/SBOM digests and signing handoff identity.

The signing event is a separate attestation linking verified build output to release key/policy, reviewer and channel. Private-key location, credential values and sensitive host details are excluded.

Reproducibility Classification

• reproducible: independent authorized rebuilds produce identical whole-artifact bytes/digest.
• content-reproducible: all signed payload objects/manifests match but ISO container bytes differ only in documented non-semantic metadata that is excluded from trusted content identity.
• non-reproducible: unexplained content or container differences; cannot enter stable channel.

Timestamps, file ordering, ownership/mode, locale, compression, ISO volume metadata and generated IDs must be normalized where tooling permits. Differences are stored and reviewed, not waived silently.

Release Record and Publication

The release record contains version/channel/status, every artifact identity, source/build provenance, SBOM, license review, security findings, supported category/tier/architecture/hardware/OS matrix, upgrade/from-version and rollback class, known issues, evidence links/checksums, release notes, support window and named approvals. Publication includes manifest/signature/digest and verification guidance.

An artifact is never “latest” solely because a filename or repository branch is newer. Signed channel indexes map stable/pilot to immutable artifact identity and retain history.

Retention

Recommended minimums pending owner approval:

• Stable release records, manifests, signatures, SBOMs, provenance, approvals and checksums: product lifetime plus seven years.
• Stable ISO/update/model/trust bytes: while supported plus two years, subject to redistribution rights.
• Pilot/RC evidence and failed critical release candidates: seven years.
• Internal/development artifact bytes: 90 days unless referenced by an investigation; metadata one year.
• Revoked/withdrawn artifacts: retain controlled bytes and permanent public/internal tombstone identity; never delete the fact that the artifact existed.
• Raw lab captures/logs: approved evidence retention, access and privacy schedule; summary/checksums follow the release record.

Retention expiration requires recorded disposition; signed metadata, security/revocation history and customer restore dependencies cannot be deleted merely to save storage.

Support Window and Cadence

Proposed policy for approval:

• One current stable MAJOR.MINOR line plus the immediately previous minor receives standard fixes.
• Critical security updates may target older supported appliances when upgrade is unsafe; unsupported lines receive a signed upgrade/recovery recommendation, not an untested patch.
• Patch/update bundles are issued as required after gates; there is no forced monthly payload churn.
• Quarterly dependency/model/runtime review determines whether a maintenance release is needed.
• ISO refresh occurs after accepted updates materially affect clean installation, security, hardware enablement or field time; installed systems use update bundles rather than OS reinstall.
• Model packs have independent revisions/support notices and do not force platform release unless runtime compatibility changes.
• Trust/revocation bundles publish immediately for approved emergency changes and on the regular maximum-age cadence required by policy.

Every release states end-of-support date or governing policy, minimum supported update source, successor release and recovery/upgrade path. No auto-update occurs without the appliance update policy.

Withdrawal and Revocation

A withdrawn artifact remains identifiable by digest and status. Signed channel indexes stop selecting it; trust/revocation policy may block new installation/import while preserving recovery-safe behavior for already-running appliances. The notice records reason/severity, affected identities, customer impact, replacement, backup/rollback advice and support contact without exposing exploit details beyond approved disclosure policy.

Evidence Gate

1. Validate filenames and manifest identity for every artifact type and architecture.
2. Generate/validate SPDX and provenance schemas; reconcile all inventory objects.
3. Rebuild independently and classify reproducibility with documented diff.
4. Verify signed channel index promotion never mutates referenced bytes.
5. Exercise withdrawal/revocation and older-version upgrade/restore discovery.
6. Confirm retention and publication locations are access-controlled, backed up and restorable.
7. Product, security, legal and delivery/support approve support/retention/cadence values.

Owner Decisions Still Open

• Approve SPDX 3.0.1 and in-toto v1.2/SLSA v1.2 formats/toolchain and reproducibility classification.
• Approve filename/version/channel rules and production publication locations.
• Approve retention periods, raw-evidence privacy schedule and legal hold.
• Approve supported-version window, security backport policy, review/ISO refresh cadence and EOL notice.
• Name release coordinator, SBOM/license owner, provenance reviewer and archive owner.