Export a Local Model Configuration Safely

Direct answer

A model-configuration export is a structured handoff of settings, not a session backup and not a model download. Its contents might identify a selected model family or revision, prompt-template label, task options, or user-editable preferences, but each field needs a clear purpose. PRIVACY-01 and COVE-MODEL-02 support separating configuration from user content and exact artifact identity; they do not establish that any app can export or safely import arbitrary model files. Define the export schema before implementing a share action. Give it a schema version, app/version context, allowed setting names, accepted value ranges, and a compatibility policy. Avoid absolute local file paths, content URIs, access tokens, signed download URLs, account identifiers, and prompts or transcripts. A model path may reveal a username or storage provider; a URL may contain credentials. If a field is needed for debugging, make it separately optional and redact sensitive parts before creating the artifact. Separate three objects: configuration, model artifact, and user session. A configuration can refer to an artifact revision but should not package its weights. A session may contain prompts, source files, edits, and generated responses and needs its own export design. A file that merely says model installed does not prove the receiving device has those exact bytes or a compatible runtime. Keep identifiers scoped to the source and avoid unsupported device-compatibility claims. Make sharing user initiated and previewable. Use a system document or share flow only after presenting the exact file name, fields, and destination choice. A picker can create or expose a URI; it does not guarantee that the receiving provider is local or that access ends immediately. Record whether the app stores a temporary export copy and when it deletes it. Never silently send the configuration to support servers or attach it to feedback. Import is also a data boundary. Validate schema version, types, lengths, and allowed values; reject unknown or executable fields rather than interpreting them. Imported values should not override permissions, credentials, endpoints, or trusted model-source policy. Treat incoming text as untrusted; validate model identifiers against known configuration and keep a user confirmation before changing active settings. Do not trust an exported config to prove artifact authenticity. Test with canary values that mimic tokens, usernames, local paths, private prompts, and signed URLs. Generate an export, inspect the bytes, share it to a controlled test receiver, revoke or remove temporary access, and search logs, cache, and recent files for leftovers. Attempt malformed, oversized, duplicate-key, old-version, and future-version imports. Confirm rejected files do not partially mutate preferences. The final report should identify build, schema version, included fields, exclusions, preview behavior, provider/recipient path, temporary-storage lifetime, import validations, and failures. It can say which synthetic config fields were included in a tested artifact. It cannot claim that exported settings are secret-free by intention alone, that a model will run on the receiving device, or that no copy remains after sharing. Re-review after adding a setting, provider, support workflow, or model artifact format.

A developer shares setup settings without sharing a prompt

A developer wants help reproducing a model configuration issue and chooses to export the selected runtime settings. The settings screen also contains a private local model path and an account token used by another feature, neither of which should appear in the shared file.

Decision

Generate a versioned allowlisted configuration, show the exact fields before a user-selected share, and test import validation separately.

Expected outcome

The recipient sees only reviewed settings and cannot infer that the source artifact or user session is included.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Export schema
• Redaction fixtures
• Round-trip import test

A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.

Implementation workflow

Record the export schema, the redaction fixtures, and a round-trip import test, and then compare them so the release notes reflect only what these recorded items demonstrate; linking the evidence this way keeps the documentation grounded in directly observed results rather than assumed behavior.

1. Define an allowlisted schema. Specify version, allowed keys, types, length limits, value ranges, and compatibility rules; exclude content, secrets, paths, and model bytes with a named owner.
2. Preview the generated artifact. Show file name, fields, redactions, and destination choice before invoking a user-selected document or share flow, and require informed confirmation.
3. Inspect bytes and temporary copies. Use synthetic canaries for tokens and paths, inspect the export, then check cache, recent files, logs, and temporary storage cleanup.
4. Validate incoming configuration. Reject unknown, malformed, oversized, or future-version fields and require confirmation before changing active preferences without partially mutating existing settings after import.
5. Test provenance and failure handling. Record provider behavior, import errors, partial-failure rollback, and the fact that configuration does not authenticate model bytes against a clean baseline.

Acceptance criteria

• The export contains only documented allowlisted fields and excludes prompts, sessions, credentials, tokens, private paths, and model weights.
• The user sees the exact artifact and destination before sharing; temporary copies and receiver URI behavior are recorded.
• Import validates schema and values, rejects malformed input without partial preference changes, and makes no device-compatibility claim.

Decision table

Failure patterns to prevent

• Including tokens or private paths
• Using export as support proof

Avoid including tokens or private paths and resist using the export itself as evidence of support, restricting any release wording strictly to what the recorded evidence confirms; this precaution ensures that statements stay aligned with the documented boundaries.

Minimum reproducibility record

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

• Android Storage Access Framework documents and files
• Android sharing simple data
• Android Keystore system

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions