Model File Integrity: Length, Hash, and Load Checks

Direct answer

Model file integrity is a chain of evidence, not one Boolean. File existence says a path is present; exact length can catch some truncation or wrong-file cases; a trusted digest can establish byte equality to an expected release; a format parser checks structural rules; and a runtime load shows a particular implementation accepted the candidate. Each result has different scope. A digest is meaningful only if its expected value is bound to the exact artifact and obtained through a trusted release channel. If the digest is absent, do not call the file hash-verified. If the runtime loads it, do not infer every task is correct or every device supports it. In the current project, E2B expected length is present but SHA-256 is an empty string, and E4B expected size and hash are explicitly placeholders. ModelDownloader skips digest verification when the configured hash is empty, then promotes its temporary file after the download path completes. ModelManager later searches for the file and attempts to initialize the inference engine. These code facts mean “download completed,” “file exists,” “digest verified,” and “runtime loaded” cannot be collapsed into one product badge. The exact integrity state for a configuration with no expected digest is “digest check unavailable,” not “passed.” Define a manifest for the final bytes, not merely a repository family. Record source repo and revision, final format, file set, expected length provenance, expected digest and how it was generated, conversion identity, and runtime requirements. If the package has companion tokenizer or model metadata files, include them in the manifest or give them separate identities with an explicit package relation. A hash of an archive is not necessarily a hash of the extracted file; label the object covered by each digest. Record algorithm and canonical representation, and compare without transforming bytes after hashing. The measurement pipeline should stream large files rather than loading them wholly into memory. Use a stable file handle or lock to prevent a concurrent writer from changing bytes while the digest is computed. Verify the final file after transfer and before activation. If data moves across storage or is copied during installation, verify the destination copy as well; source validation does not prove a later copy is intact. Treat temporary and active paths separately and never repair by silently truncating a potentially good artifact. When a check fails, preserve diagnostic distinctions: expected length unavailable, length mismatch, digest mismatch, parser rejection, runtime load rejection, and task acceptance failure. Remove or quarantine only the candidate artifact when policy allows, retain logs without user content, and keep the last known-good model. A matching digest does not prove license or provenance if the expected digest itself is untrusted. TLS transport also does not replace an artifact digest. Conversely, a missing digest does not automatically mean the package is corrupt; it means one assurance is absent and release policy must decide whether remaining checks are sufficient for a limited internal test. Validate checks with controlled fixtures: exact known bytes, truncated file, changed byte with same length, wrong expected hash, manifest from another revision, missing companion file, parser-invalid header, and runtime rejection. A test should prove not only that an error is surfaced but also that the invalid candidate cannot become active or delete user data. For production wording, report the evidence actually available and do not generalize from one passing host test into device compatibility. ### Procedure 1. Identify the exact object under test: source or final package, revision, format, companion files, file location, and manifest field that supplies expected values. 2. Validate byte length and digest separately. Record the expected value’s provenance, digest algorithm, target file, and whether hashing occurred before or after any transformation. 3. Parse package structure and verify companions. Keep parser results separate from file identity so a structurally valid but wrong revision is still rejected. 4. Load the verified candidate with the intended runtime and record initialization. Run a representative task only after artifact checks, and preserve each stage as its own result. 5. Test mismatch and recovery fixtures. Quarantine only failed candidate bytes, preserve active artifact and user records, and make missing digest evidence visible instead of fabricating a pass. ### Acceptance criteria - Existence, length, trusted digest, package parsing, runtime load, and task acceptance are independently represented. - An absent or placeholder digest is never described as verified; expected digest provenance is recorded. - Final bytes and any copied destination are checked against the right manifest object before activation. - Invalid candidates cannot replace the active model or trigger deletion of unrelated user data. ### Comparison | Check | What it can detect | What it cannot establish alone | |---|---|---| | File length | Some truncation and wrong-object cases | Byte equality, publisher identity, or loadability | | Trusted cryptographic digest | Equality to the expected byte sequence | License, runtime compatibility, or task quality | | Runtime load | The selected runtime accepted this candidate | Correct user task, device-family support, or provenance | ### FAQ **Is a model file verified if it exists and has the expected length?** Not fully. Length can detect some mismatches, but different bytes can have the same length. Use a trusted digest when available, then parse and load the exact package. **Can an empty checksum field be treated as a successful check?** No. It means no expected digest was provided, so the digest check did not run. Report it as unavailable rather than passed. **Does a matching SHA-256 prove a model is safe or licensed?** No. It proves equality to the expected digest only if the expected value is trustworthy. Provenance, license, format, runtime, and task acceptance need their own records. **Should the app hash a multi-gigabyte model in memory?** No. Stream the file through a bounded buffer, prevent concurrent modification, and identify exactly whether the digest covers an archive, package, or extracted file.

A model file exists but its expected hash is missing

A release candidate has downloaded to local storage, and the app sees the expected filename and a plausible length. The configuration has no expected SHA-256 value, so the team must describe the verification state without overstating the evidence.

Decision

Report length and file-presence checks separately, mark digest validation unavailable, then inspect the package and perform runtime/task checks under release policy.

Expected outcome

The candidate is either accepted for the explicitly scoped test or remains unverified; no false “checksum passed” state appears.

Evidence to collect

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

• Expected length
• Trusted SHA-256
• Load result

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

Implementation workflow

1. Define the object and manifest scope. Specify whether the expected metadata covers the downloaded package, an archive, or an extracted component. Bind source revision, format and companion files before checking bytes.
2. Check length and digest independently. Record where expected length and digest came from. If the digest is empty or placeholder, label it unavailable and do not skip silently; compute only against a trusted release value.
3. Prevent changes during verification. Use one owner or stable file handle while hashing. After any copy or install move, verify the destination object instead of assuming the original check covers the copy.
4. Run parser and runtime stages. Inspect format structure, then initialize the intended runtime with the exact candidate. Keep a load failure separate from byte mismatch and do not expose unsupported fixes.
5. Reject safely and retain recovery. Use known-byte fixtures to test truncation, same-length changes, wrong hash, and malformed package. Quarantine candidate only; preserve the working artifact and user content.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• A missing checksum is recorded as unavailable, not as a successful validation.
• Length, digest, parser, runtime, and task outcomes are separate fields tied to the exact artifact.
• Any installation copy is validated at its destination before activation.
• A mismatch cannot replace the working artifact or delete unrelated user data.

Decision table

Failure patterns to prevent

• Calling length a hash
• Skipping digest while claiming verification

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

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 Gemma 4 model page
• Java MessageDigest API
• LiteRT-LM package header schema
• Android storage access framework

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

Frequently asked questions