Stable and Preview Update Channels for Local AI

Direct answer

An update channel is a release policy that selects which immutable model artifact and companion configuration a user may receive; it is not just a mutable URL named stable or preview. Define channel membership, eligibility, artifact revision, runtime and parser requirements, user consent, promotion criteria, and rollback behavior before exposing a channel. A stable channel should point to a reproducible, reviewed release record. A preview channel can expose a candidate to a limited, consenting cohort, but the label “preview” does not excuse missing artifact identity or safety checks. Keep model channels separate from Android application tracks. Play Console tracks govern which app package a selected tester or audience receives. A model channel inside an app governs which external artifact and metadata the model manager fetches. If both have stable and preview labels, name and record them independently. A user can install a stable app and still be offered a preview model, or install a test-track app with a stable model. The release interface should show both identities and avoid implying one proves the other. Bind a channel manifest to immutable inputs. At minimum, record model family and exact variant, repository and commit or revision, artifact file names and expected lengths, digest and source if available, accepted format, required runtime range, tokenizer or processor identity, prompt and parser versions when they affect outputs, and release notes. If an expected digest is absent, say verification is limited; do not fill the field with an unverified value. A channel pointer may select a manifest, but downloaded bytes must still be compared against that manifest. A branch such as “main” can move; a release record should resolve to a fixed revision or otherwise describe its mutability. Define eligibility and promotion in evidence terms. Preview users may opt in to a candidate and provide consent for the specific change. Test required tasks, model load, output schema, cancellation, storage, and rollback. If performance or named-device support has not been measured, do not use those claims as promotion criteria or public copy. Promote only after the evidence required by the release policy is present, and retain the exact candidate-to-stable mapping. If a candidate fails, restore the prior artifact reference without deleting user data or derived state that still belongs to the old revision. Treat channel changes as state transitions. Persist the selected channel, installed artifact identity, available update identity, and migration status separately. On app restart, reconcile the current selection with the manifest; never silently convert a preview user to stable or the reverse. If the selected channel is unavailable, show that state and a user-controlled fallback rather than fetching an arbitrary latest file. An update should not replace an active model while the runtime is using it unless the application has a tested safe switch strategy. A channel is not a cryptographic trust mechanism. HTTPS and a familiar host do not by themselves prove artifact origin, and a channel name does not establish license, safety, device compatibility, or output quality. Preserve source provenance and any trusted verification evidence separately. For license decisions, reference the terms for the exact artifact and distribution route; do not assume a release channel changes licensing rights. This article describes a release design and does not claim that Cove currently publishes preview or stable model channels.

Offer a candidate model to opt-in testers

A team wants to try a new artifact with a limited group while other users keep the current model. Play internal testing distributes the app, so model selection needs its own release record.

Decision

Create a separate opt-in model channel with immutable manifest, declared runtime needs, explicit promotion evidence, and a rollback reference.

Expected outcome

A tester can tell which app and model they have, and a failed candidate can be withdrawn without losing prior user data.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Channel manifest
• Promotion criteria
• Rollback test

A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.

Implementation workflow

The evidence to be recorded and compared includes the Channel manifest, the Promotion criteria, and the Rollback test. Each of these items documents the configuration, the conditions required for advancement between channels, and the verification steps needed to confirm that prior states can be restored, together forming a consistent comparison across channels.

1. Separate app and model tracks. Store application-package track and model channel as independent release facts. Document who receives each and how an app on one track may use a model on another.
2. Pin the model release record. Record repository revision, artifact file identity, format, expected length, digest provenance, runtime and processor needs, prompt/parser versions, and date. Preserve unknowns instead of inventing fields.
3. Define eligibility and opt-in. Specify cohort, consent, rollout, channel-switch visibility, and fallback. Limit candidates to users whose tested task and data policy allow the change.
4. Set evidence-based promotion. Run the release’s functional, recovery, schema, and compatibility checks for its declared scope. Exclude unmeasured speed/device statements and disclose remaining limitations.
5. Switch and roll back safely. Keep the active model until candidate verification and loading pass. Version or invalidate derived state explicitly, retain the previous manifest, and never delete user-created records.
6. Exercise withdrawal paths. Test missing manifests, revoked candidates, interrupted transfer, verification and load failures, channel withdrawal, restart, and reversion to the prior release.

Acceptance criteria

• Stable and preview names resolve to explicit versioned manifest records rather than only mutable filenames or branches.
• Android app testing tracks and model-artifact channels are separate in storage and user-facing copy.
• Promotion uses reproducible evidence; unmeasured performance and device compatibility claims are excluded.
• Channel changes preserve user data and have a tested rollback if candidate verification or loading fails.

Decision table

Failure patterns to prevent

• Sharing mutable latest artifacts
• Mixing preview-derived state into stable

Common pitfalls include sharing mutable latest artifacts and mixing preview-derived state into stable, both of which undermine the separation between channels. Release wording should therefore be limited strictly to what the recorded evidence demonstrates, avoiding any claims that extend beyond the documented manifest, criteria, and rollback verification.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Cove benchmark method
• Download a specific Hugging Face revision
• Build and test an Android App Bundle
• Android app signing and release identity

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions