Direct answer
A saved model result is only interpretable when the app can identify what produced it and what later transformations were applied. Versioning should link a result to its source record, model artifact identity when available, runtime, prompt/template revision, parser/schema version, and user edits. `COVE-MODEL-02` records that a current configured artifact hash is absent, so the application cannot claim digest-level provenance for that artifact. `BENCHMARK-01` requires exact artifact and runtime information for result evidence. This guide addresses stored-result provenance and migration, not repeated-output benchmark scoring. Start with a result envelope that is small enough to maintain but sufficient to explain a saved item. Give the result a stable ID, source ID, created time, task type, input language/format if known, output state (partial, reviewed, accepted), app schema version, and provenance fields actually available. Do not record secrets or full prompts just to make history traceable. If the app cannot identify a model revision, store an explicit unknown value rather than fabricating a name from the family or filename. Separate immutable source from derived output. When the prompt changes, parser changes, or model artifact is replaced, the old result should remain associated with the old configuration. A new run should create a new result or a well-defined revision, not overwrite history. If a migration changes the result schema, provide a versioned conversion with rules that preserve unknown fields or mark them unavailable. Do not silently reinterpret an old translation under a new tokenizer or language policy. Keep user edits linked to the exact generated draft they changed. Design query and display behavior around provenance. A history card can show a task date and status without exposing the entire source text in notifications or logs. A user opening a result should be able to inspect source and output, identify that it was generated under an older app/model configuration when known, and decide whether to rerun. Search indexes or summaries derived from results need their own version and deletion linkage; deleting a visible result must not leave a stale searchable snippet. The result record should not claim the source was accurate or that the output was verified unless a human or deterministic validator actually did so. Test database upgrade and rollback using synthetic result records from each supported schema version. Include unknown provenance, partial output, edited output, rejected output, missing source, duplicated migration, and interrupted migration. Verify idempotence: running the same migration twice should not duplicate or erase records. Test after process death and app update, then compare source IDs, result state, and derived index references. If export or backup includes results, ensure version fields survive and explain whether the model artifact itself is separate from result history. Keep deletion and privacy coherent. Provenance should not become a hidden identifier that persists after user deletion. Map source, result, edits, derived indexes, thumbnails, caches, and backup entries to retention and deletion behavior. A migration must not restore old consent or reintroduce deleted content. When necessary evidence is missing, the UI may say “model version unknown” and offer rerun; it should not imply the result is reproducible. The release report identifies schema revisions, migration path, preserved fields, unknowns, and test fixtures. It can demonstrate that stored results remain interpretable under a known schema; it cannot establish translation accuracy, task quality, or exact model provenance if the artifact identity was unavailable. This narrow approach keeps old user work understandable while preventing silent changes from making a historical result look newly verified.
A user opens a translation saved before a model update
The app has updated its model or prompt configuration since the translation was created. The user wants to know whether the saved output came from the current version and whether rerunning will replace the original.
Decision
Keep the historical result and its recorded provenance, expose unknown fields honestly, and create a new revision only after an explicit rerun.
Expected outcome
The old result remains distinguishable from a new one, and the user can compare or retain both without a false verification claim.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Result schema version
- Artifact reference
- Migration fixtures
Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.
Implementation workflow
- Define a versioned result envelope. Record stable source/result IDs, task type, output state, schema version, and provenance fields that the application actually knows. Use explicit unknown markers.
- Preserve immutable history and revisions. On prompt, parser, or artifact change, retain the old record and create a new result or defined revision. Link user edits to the exact draft they modify.
- Specify schema migration policy. Version each stored format, preserve fields when possible, and mark unavailable values rather than inventing provenance or silently reinterpreting content.
- Test upgrades, rollback, and interruption. Migrate synthetic records from supported versions, repeat migrations, interrupt the process, and verify IDs, partial/review status, and derived index links remain correct.
- Align search, export, deletion, and backup. Verify derived snippets and exports retain version labels, deletion removes linked derivatives, and backups or migrations do not resurrect deleted content or stale consent.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Each saved result identifies source and schema version plus available provenance; unknown artifact identity is explicit rather than inferred.
- A model/prompt/parser upgrade preserves the historical item and creates a distinct rerun/revision without silently changing the old result.
- Repeated and interrupted migrations preserve state, user edits, deletion linkage, and version fields in any tested export.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Unversioned saved text | Store only rendered output | Readable but hard to interpret after prompt, parser, model, or schema changes. |
| Versioned result envelope | Source, state, schema, and known provenance | Supports explanation and migration while explicitly retaining unknowns. |
| New rerun | Create a new linked result | Lets the user compare versions without overwriting historical work. |
Failure patterns to prevent
- Overwriting old provenance
- Reinterpreting old output silently
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
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 benchmark method
- Android Room database migrations
- Android data layer and source of truth
- Android app architecture guide
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Should an app store the full prompt to reproduce every result?
Not automatically. Store only justified provenance; prompts can contain private data. If exact reproduction is unavailable, record the limitation instead of expanding retention silently.
Can a filename identify which model generated an old result?
Not reliably. A filename or model family may not identify exact bytes or revision. Use a trusted identity when available and mark missing provenance as unknown.
Should migration update old outputs to the new model?
No. Preserve historical output and offer an explicit rerun that creates a new linked result. A migration should not silently regenerate or relabel user content.