Direct answer
Surface a privacy-respecting diagnostic mode that only reveals runtime and artifact evidence once a user deliberately activates it, so no internal state is exposed by default. The boundary identifiers PRIVACY-01 and PRIVACY-02 frame the rule that explicit user action must occur before any evidence becomes visible. Nothing in this paragraph should imply behavior beyond that single consent gate.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Diagnostic schema
- Redaction fixtures
- Enable, export, and disable tests
A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.
Implementation workflow
Connect the available evidence by recording it through a clearly defined diagnostic schema, exercising it with redaction fixtures, and verifying the full enable-export-disable sequence with focused tests that capture and compare results. Each artifact, fixture, and test outcome should be logged so later comparison can confirm that redaction held and that enabling or disabling followed the expected path, without interpreting any deeper system behavior.
- Inventory every content and metadata type.
- Enumerate every destination and trigger.
- Map user action to code path and request fields.
- Verify the core task in airplane mode.
- Capture traffic for setup, inference, diagnostics, and export.
- Update public disclosure in the same release as behavior.
Failure patterns to prevent
- Logging raw content
- Leaving diagnostic mode enabled silently
Avoid two specific pitfalls when wording any release notes: never describe logging raw content, and never describe leaving diagnostic mode enabled silently. Phrasing must be confined to evidence already recorded under PRIVACY-01 and PRIVACY-02, so statements only reference what the schema, fixtures, and tests have captured, not any unrecorded state.
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 端侧专题.