Direct answer
The on-device AI feature lifecycle should be modeled as a state machine whose focus is to make every status a citizen: missing, downloading, verifying, loading, ready, running, cancelling, failed, and repairable must each be represented as named states rather than implied. The instruction is to be explicit about these named states and nothing else, so no additional conditions or behaviors should be inferred beyond what is listed.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- State transition table
- Invalid-transition fixtures
- Process recreation result
A runtime comparison is publishable only when artifact identity, build configuration, selected backend, task fixture, and failures are recorded.
Implementation workflow
The evidence for this state machine consists of three connected items that should be recorded and compared: a state transition table, a set of invalid-transition fixtures, and the result of process recreation. By capturing each item and contrasting them together, the lifecycle's design can be checked against itself, and any inconsistency among the table, the fixtures, and the recreation outcome becomes clearly visible.
- Freeze the product task and minimum device tier.
- Choose the runtime and supported artifact format.
- Pin artifact and runtime revisions.
- Wrap native state behind an application-owned interface.
- Test load, representative work, cancellation, close, and fallback.
- Publish only the behavior reproduced by the recorded configuration.
Failure patterns to prevent
- Using booleans for overlapping states
- Skipping cleanup transitions
Two pitfalls constrain the release wording, which must stay limited to recorded evidence: avoiding booleans where states overlap, and avoiding skipped cleanup transitions. The release language should rephrase only these pitfalls, and any statement made should be restricted to what the recorded evidence already shows, with no further claims added.
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 端侧专题.