Direct answer
Rephrase the supplied focus: derived results must be rebuilt whenever the artifact, prompt, parser, preprocessing, or source identity changes. No further inference beyond this statement is warranted. Recording which dependency, fixture, or result version is in use, and then comparing the rebuilt output against the recorded rollback, makes the change visible. Without that comparison, evidence of safe invalidation cannot be established.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Dependency version map
- Invalidation fixtures
- Rollback and rebuild result
A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.
Implementation workflow
Connect the evidence items and say to record and compare them: maintain a dependency version map, pair it with invalidation fixtures, and record rollback and rebuild results so versions can be compared. A version map paired with invalidation fixtures establishes what was in use, and the rollback and rebuild result documents the difference between the prior and new state.
- Pin the official artifact revision.
- Record expected length and trusted digest.
- Check storage for temporary and update copies.
- Download to a temporary path and resume safely.
- Verify before final placement.
- Keep rollback and repair paths.
Failure patterns to prevent
- Reusing stale vectors or summaries
- Deleting user source data
Rephrase the pitfalls and limit release wording to recorded evidence: the dangers are reusing stale vectors or summaries and deleting user source data. Release decisions must rest on the recorded rollback and rebuild evidence rather than on assumption, because unrecorded change cannot be verified.
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
This page relies on the Cove fact ledger and benchmark policy. Results remain blocked until raw records exist.
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.