Direct answer
A local model release manifest is a versioned record that lets a reviewer identify what the application is expected to load and which evidence supports that identity. It should connect a model name to an immutable upstream revision, the exact file set, declared format, byte lengths, any trusted digest, tokenizer or processor files, conversion steps, runtime revision, and the application contract that consumes the artifact. The manifest also records the app release that expects it, compatibility decisions that were actually made, and the previous known-good artifact or recovery action. It is an operational index, not a cryptographic proof by itself. Keep source identity separate from downloaded-file identity. A repository URL or model-family label can point to changing content; pin a commit or release and list every file needed by the task. Record a SHA-256 only when it came from a trusted source or was calculated from the bytes under review. Cove facts currently identify a pinned Gemma 4 E2B development artifact and expected length, while its configured SHA-256 is empty. That means a manifest can record the configured identity and say digest unavailable, but must not claim the artifact was digest-verified. A measured local hash is useful for later comparison only if the release process preserves and trusts the value. For each conversion or repackaging step, record input and output identities, tool and version, configuration, and operator or build job. If an upstream file becomes a converted artifact, the two digests answer different questions; neither proves that conversion preserved task behavior. Keep license and notice references attached to the exact source artifact, but do not treat a URL, model card, SPDX identifier, or provenance file as a legal approval. The release reviewer still needs to read the terms that apply to the actual variant and distribution path. SLSA provenance describes verifiable information about where, when, and how a software artifact was produced. The in-toto Statement identifies the produced subject and digest; the SLSA provenance predicate describes the build definition, resolved dependencies, builder, and run details. These formats can carry stronger build evidence when an appropriate builder creates and signs an attestation, but a spreadsheet or JSON file assembled by hand is not thereby a verified attestation. A model manifest may link to such evidence while clearly labeling whether it is absent, unsigned, unverifiable, or verified by a named verifier. Treat runtime and task configuration as part of the release contract rather than as model-file metadata. Record the runtime package and version, expected input modality, tokenizer or chat template, prompt revision, output parser or schema, and any limit or fallback policy that changes interpretation. Do not put user prompts, recordings, photos, or health data in the manifest. A synthetic fixture identifier and a result-record reference are enough to connect a validation run without making the manifest a content archive. A useful release comparison is between the old manifest and the proposed one. The reviewer should see exactly which artifacts changed, which checks were repeated, which claims became unknown, and how to restore the previous known-good set. If the deployment system cannot restore an old model, describe the actual repair path instead of promising rollback. The goal is to make model changes reviewable and reproducible; it is not to announce universal compatibility, a quality improvement, a security certification, or public availability.
A model update changes more than one file
A release engineer receives a converted model package after the upstream repository changes. The package contains several weight and tokenizer files, the runtime dependency also changed, and a previous test report refers only to the model family name. A reviewer must decide what can be approved without confusing the new package with the old tested configuration.
Decision
Create a release manifest that pins the upstream revision and every artifact, labels missing digests honestly, records the runtime and prompt/parser contract, and links only to validation evidence that used those exact inputs.
Expected outcome
The reviewer can identify the changed inputs and the recovery path. The record makes no claim that the new artifact has a verified hash or that a prior run covers the changed runtime.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Manifest schema
- Artifact verification
- Release and rollback mapping
A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.
Implementation workflow
The descriptor groups must be recorded together under the manifest schema, verified at the artifact level, and mapped consistently between release and rollback states. Comparing these recorded entries ensures that each declared field is traceable across versions and that rollback references align with the originally captured values. No synthesis beyond the listed groups is permitted.
- Pin the source and enumerate the artifact set. Record the official source location, immutable revision, exact filenames, declared format, tokenizer or processor companions, and expected lengths when a trusted value exists. Do not substitute a family name, latest tag, or a lone shard for a complete package identity.
- Record transformations and integrity evidence. For each download, conversion, quantization, or repackaging stage, preserve input and output digests, tool version, configuration revision, and result. Mark a digest as unavailable when there is no trusted reference; calculating a local checksum does not retroactively verify an upstream publisher claim.
- Bind the package to its execution contract. Add runtime name and resolved version, application build, tokenizer or template revision, prompt revision, parser/schema version, task fixture identifier, and fallback policy. Keep private user content out of the manifest and link to a redacted test record instead.
- Attach provenance and license references accurately. Link a SLSA or in-toto attestation only when it describes the exact artifact and its subject digest. Record its signer, verifier, and outcome if checked. Separately link the authoritative terms for the exact model variant and keep unresolved redistribution or notice questions visibly open.
- Compare releases and define recovery. Diff the candidate manifest against the currently approved one, list changed inputs and checks that must be repeated, then name the actual restore or repair procedure. Do not label a fallback artifact as recoverable unless it is retained and can be loaded by the target release.
Acceptance criteria
- Every model package entry is tied to an immutable source revision and a complete file list; unavailable digest evidence is explicitly marked.
- The manifest distinguishes artifact identity, transformation history, runtime contract, task evidence, license references, and signed provenance.
- A reviewer can identify what changed and follow a documented restore or repair path without relying on a family name or unsupported compatibility claim.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Model-family label | Human-readable name only | Useful for navigation but cannot identify a revision, shard set, converter, or runtime. |
| Release manifest | Versioned inventory with evidence links | Makes inputs and decisions reviewable; does not independently prove publisher identity or signature validity. |
| Verified attestation | Signed provenance checked against an expected signer and subject digest | Can support a defined supply-chain claim when its builder and verification policy are trusted; does not establish model quality or task compatibility. |
Failure patterns to prevent
- Mutable artifact references
- Missing parser or prompt identity
Two boundaries constrain the wording of a release: mutable artifact references, which must never appear as recorded evidence, and missing parser or prompt identity, which must likewise be excluded. The release statement may only summarize what the manifest already records, keeping every declaration limited to verified, non-mutable fields.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
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 Gemma 4 model page
- SLSA v1.2 Provenance: artifact inputs, builder, and build record
- in-toto Attestation Statement v1: subject and predicate binding
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Does a locally calculated SHA-256 prove a model came from its publisher?
No. A local digest identifies the bytes you hashed. To verify publisher integrity, compare it with a trusted expected digest or verify an authenticated attestation under a defined trust policy.
Is a release manifest the same as SLSA provenance?
No. A manifest is an application-owned inventory and decision record. SLSA provenance is a structured statement about a build and its inputs; it requires trustworthy generation and verification before it supports a provenance claim.
Should prompts or sample user conversations be stored in the manifest?
No. Store a synthetic fixture identifier, prompt revision, and a reference to an appropriately protected test report. A release inventory does not need private task content, and reviewers should not copy real prompts into build metadata.