Direct answer
The work focuses on offline document summarization on Android, and it centers on the narrow set of activities already named: version ingestion, chunking, prompt construction, artifact production, and required-fact acceptance. Readers and reviewers should treat the description as complete only with respect to these activities and should not infer additional stages, models, or behaviors beyond them. Any claim not directly tied to one of these items falls outside the stated focus.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Document fixtures
- Required facts and forbidden additions
- Long-document failure path
Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.
Implementation workflow
The test setup uses document fixtures as inputs, requires summaries to contain every required fact while avoiding forbidden additions, and exercises a long-document failure path to expose weaknesses. Reviewers are asked to record the outcomes of each item and then compare them side by side, so the relationship between the fixtures, the fact and restriction lists, and the failure case can be examined together rather than in isolation.
- Write the user promise and offline requirement.
- Separate source data from derived output.
- Define typed stage contracts.
- Create privacy-safe fixtures and expected properties.
- Test each stage without hiding partial failure.
- Run the complete task in airplane mode and through lifecycle changes.
Failure patterns to prevent
- Judging fluency only
- Losing source provenance
Two pitfalls deserve attention. First, judging summaries by fluency alone can mask missing facts or hidden additions, so evaluation must look at content coverage rather than surface polish. Second, losing source provenance breaks the link between a statement and its origin in the fixtures, undermining any claim of correctness, and release wording should therefore be limited strictly to what the recorded evidence supports.
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 端侧专题.