Direct answer
A local-model metadata screen should report what the application can observe about the current artifact and label what it cannot prove. Separate configured identity, installed-file evidence, verification state, and runtime state. Show an artifact name plus an immutable revision or manifest reference when the source provides one; show file size only with its measurement source and meaning; distinguish a missing digest from a digest that was checked and matched; and report whether the manager considers a model not downloaded, downloading, downloaded, loading, ready, or in error. A model name such as “Gemma” is a family label, not enough to identify exact bytes. This screen is not a model picker. A picker asks which option a user wants; a metadata view explains the evidence for the currently selected or installed option. It is also not a verification engine: rendering a green badge does not perform a hash, format, or runtime check. Each displayed claim must be backed by a value collected from the relevant source, with timestamp or revision where useful. If the app cannot determine a field, show “not provided” or “not checked,” not a guessed value. Avoid device-support badges unless a tested compatibility matrix supports them; model size or architecture alone does not establish that a particular phone can load the model. The repository’s current model configuration demonstrates why provenance matters. The fact ledger records a pinned Hugging Face commit and an expected byte count for one configured E2B artifact, but it also records that the configured SHA-256 field is empty. That expected length can support a configured-size display for that source snapshot; it cannot be described as a measured size of a publicly distributed Cove APK, proof that a user’s file matches the artifact, or a successful checksum. Do not extend those facts to another variant, installation, or future configuration without checking its own source. A status view should say “expected size from configuration” rather than “verified file size” until the actual file has been measured and compared under a defined rule. Use separate fields for the configured source and the local file. Configured source may include artifact family, selected variant, pinned repository revision, filename, and expected byte length. Local evidence may include whether a file exists, actual byte length, last modified time if reliable, access location, and whether the app has run its configured checks. Runtime status is separate again: a file can exist but be inaccessible, still downloading, waiting for initialization, failing to load, or ready for a tested path. The UI must not infer one state from another. “Downloaded” is not “verified”; “verified” is not “loaded”; “loaded” is not a benchmark result. Design the detail screen around decisions users can make safely. Give a plain-language explanation of the artifact and status, provide a way to retry or repair only if the application implements it, and expose a copyable support summary that omits secrets. A useful summary can include app build identifier, model configuration revision, artifact variant, expected and observed byte counts, digest availability and result, lifecycle state, and a non-sensitive error category. It should not include a signed download URL, authorization headers, prompts, transcripts, or private file contents. Keep actions distinct: selecting a different variant belongs to the picker; removing an artifact belongs to a deletion flow with explicit scope; rechecking integrity belongs to an actual verifier. Avoid turning estimates into UI facts. If a configured length is a placeholder, mark it as such or omit it from a user-facing certainty label. If a file path is in application-private storage, show a broad location description rather than exposing a raw absolute path that can become invalid or disclose implementation details. If an external volume is used, indicate that the volume may be unavailable and provide a recovery action only when implemented. If a digest is missing, say no trusted expected digest is configured; do not show “secure,” “authentic,” or “verified” based on the model’s title or source hostname.
Diagnose a model-related support request
The user reports an offline task is unavailable after an update. The device might have no file, an older revision, incomplete bytes, an unavailable digest, or a runtime load error.
Decision
Show source-backed configuration and actual local observations as separate fields, with unknown values explicit and no implied compatibility badge.
Expected outcome
Support can identify a tested next step without confusing expected size, file existence, digest verification, runtime readiness, or release status.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Artifact revision and format
- File length and digest state
- Installed and load status
A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.
Implementation workflow
Connect the artifact revision and format with the file length and digest state, and join both with the installed and load status indicators. Record each item, compare them against one another, and ensure that no claim moves beyond what the recorded fields collectively confirm.
- Map field ownership. Trace name, variant, pinned revision, expected length, expected digest, local file observations, and lifecycle state to the manifest, ModelConfig, filesystem query, or manager that owns each value. Mark configuration, measurement, derivation, and unknown separately.
- Separate remote and local evidence. Display configured expected length apart from observed file length and runtime state. Do not use a remote manifest value as if it were a measurement from the file stored on the user’s device.
- Name the verification result. Represent digest absent, not run, mismatch, and match to a trusted expected value as different states. File existence, extension, filename, or a completed transfer must never imply integrity or authenticity.
- Bind actions to tested flows. Link to a real picker, retry, repair, or removal operation only if the application implements it. Verify effect on the active artifact and user data, and keep selection controls out of a read-only evidence view.
- Create a redacted support summary. Include app build, config revision, artifact variant, expected and observed lengths, state, and safe error category. Exclude prompts, documents, signed URLs, authorization data, and raw private URIs.
- Test missing and changing states. Cover absent file, stale revision, incomplete download, empty digest, manager error, load failure, and success. Confirm labels follow observed state and never assert device support without a corresponding test.
Acceptance criteria
- Each value is labeled as configured, observed, verified, derived, or unknown according to its evidence source.
- An absent expected digest appears as missing evidence, not a successful hash check or authenticity badge.
- Download, verification, runtime loading, ready, and error remain separate; this view does not change the selected model.
- Support output excludes user content, prompts, authorization headers, signed URLs, and private document URIs.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Model picker | Answers which available option the user wants. | Presents choices and consequences but does not prove current bytes are valid. |
| Model metadata | Answers what is configured or observed for this artifact. | Reports sourced identity and state without silently changing selection. |
| Compatibility report | Answers whether a defined task test passed on a defined device. | Requires a device-and-task test; name, size, and architecture alone are insufficient. |
Failure patterns to prevent
- Displaying family name as full identity
- Showing unverified support badges
Avoid displaying the family name as if it were the complete identity, and do not present unverified support badges. Restrict any wording suitable for a release to what the recorded evidence items establish, so the screen reflects only the items present in the evidence set.
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
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Can an expected configured length be shown as installed file size?
No. It comes from configuration rather than local measurement. Label it expected and show an observed byte count separately after safely inspecting the actual file.
Should the details page show a green verified badge?
Only after a real verifier compared bytes against a trusted expected value and its scope is explained. Missing digest means not configured; a successful runtime load is a separate result.
Should model metadata include device recommendations?
Only with a tested compatibility source for the exact device, artifact, runtime, and task. Parameter count, expected file size, RAM, or family name alone cannot prove support.