Version Consent for Hybrid AI Routes

Direct answer

Version a remembered route choice against the disclosure and behavior it described, not just a boolean such as 'cloudAllowed=true'. A usable record identifies the feature, route policy revision, destination category, purpose, data categories, whether optional content may be sent, user choice, and the app version that presented the choice. It should also distinguish “not asked,” “declined,” “allowed for this request,” and “remembered for this narrowly scoped feature” if the product supports each state. A stored value only proves that the application wrote a choice record; it does not prove what text was displayed, which payload was later sent, or that the flow satisfies a legal requirement. The key operation is comparing the current route contract with the one a prior choice covered. A material change can include a new recipient, a new purpose, a broader payload such as full conversation history instead of a selected excerpt, a new automatic fallback, or a route that moves data off-device where it previously stayed local. Do not silently inherit an old decision across those changes. A copy edit that does not alter the data flow may not need to force a new choice; define materiality in a reviewed product policy rather than equating every version number with a prompt. Preserve a link to the disclosure revision and payload schema so reviewers can reconstruct that decision. Represent the route as versioned data rather than scattered UI flags. A typed record might include featureId, routeId, routeRevision, recipientClass, purposeRevision, payloadClassSet, disclosureRevision, choice, and a timestamp. Use a stable schema version for the record itself, separate from the product route revision. Unknown or missing fields after an app upgrade should not be interpreted as permission. Migrate only states whose meaning remains clear; otherwise return the feature to a “review needed” state and show the current choice screen before creating a remote request. Do not store user prompts or document contents in the consent record as evidence. Scope persistence narrowly. A one-time confirmation should attach to one request ID and expire with that request. If a product offers a remembered preference, bind it to the specific feature, route, payload categories, and purpose that were disclosed. Revocation should invalidate that record and prevent new transfers. Decide how already queued work behaves: cancel it, pause it for review, or finish only when the user-facing contract explicitly permits that behavior. A retry to a different recipient or with a larger context is a new route decision. Network failure is not permission to widen the route. On Android, a small typed or key-value record can live in an app data layer such as DataStore, but the storage API does not define consent semantics. Keep the route policy in one authoritative component and expose an observable state to the UI. Before a request is assembled, check that the current policy revision still matches the saved choice and that the proposed fields are within its scope. If not, block the request and request review. On account reset, app-data restore, or policy migration, do not resurrect a stale authorization without checking the current route and disclosure revision. Test transitions, not just the consent screen. Use synthetic canary fields and capture whether any network request begins after no choice, decline, revoke, route revision change, purpose change, payload expansion, app upgrade, process recreation, connectivity loss, and retry. Compare the visible disclosure, stored record, request destination, and serialized payload. Play Console guidance says disclosure and consent duties depend on the data and user expectations, and its Data safety form must reflect actual app and SDK data practices; these pages are policy references, not a determination that a particular implementation is legally sufficient. The published Cove privacy boundary also distinguishes user content from model downloads, Play purchase verification, newsletter signup, and optional crash reporting; do not collapse those routes into a single “cloud consent.” The review result should state which revision was tested and which choices remain valid after each change. It can show that a particular app build blocks a request until a matching decision exists. It cannot certify legal consent, prove all transfers are disclosed, or establish a particular app route without code and traffic evidence.

A local rewrite gains a remote fallback after an app update

A user previously chose a local-only rewrite route. A later build adds an optional remote provider that can receive selected text when a local task is unavailable, and a queued retry may still exist from the old build.

Decision

Treat the destination and route behavior as a new revision, prevent the old record from authorizing the remote request, and present a request-specific choice before sending selected text.

Expected outcome

The task remains local, waits for the user’s decision, or sends only the approved fields; app upgrade and retry do not silently transfer prior content.

Evidence to collect

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

• Consent schema revision
• Route and payload fixtures
• Revocation and upgrade tests

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

Implementation workflow

Record the consent schema revision alongside the route and payload fixtures, then compare these artifacts against the outcomes of revocation and upgrade tests. This alignment ensures that each captured choice corresponds with the precise documentation and verification evidence already gathered.

1. Define the route contract. For each feature, version destination category, purpose, payload classes, trigger, local alternative, retry behavior, and disclosure text. Separate material data-flow changes from cosmetic wording changes.
2. Create a versioned choice record. Store feature and route identity, policy and disclosure revisions, scope, choice state, and request binding where appropriate. Keep record-schema migration separate from route-policy revision.
3. Gate request construction. Before serializing a request, compare the current route and proposed fields with the saved choice. Unknown versions, missing scope, declined state, or revoked state must block transfer and return to review.
4. Handle upgrade, queue, and revocation. Define what happens to queued work and remembered choices after material changes, app restore, account reset, connectivity loss, and user withdrawal. Never widen recipient or payload on retry.
5. Verify disclosure and actual traffic. Use synthetic canary fields to test no-choice, allow, deny, revoke, policy migration, route change, and failure paths. Compare the visible copy, stored revision, destination, and payload fields.

Acceptance criteria

• Every remembered choice names the route, destination category, purpose, data scope, and disclosure revision it covers.
• A material recipient, purpose, or payload change cannot reuse an out-of-scope choice or send a request before renewed review.
• Decline and revoke block queued or new transfer according to the documented policy, and synthetic canaries confirm the behavior.

Decision table

Failure patterns to prevent

• Reusing consent after scope change
• Transferring before upgrade review

Avoid releasing on the basis of reusing consent after any scope change, and refrain from transferring before an upgrade review. Restrict approval statements to the evidence that has actually been recorded, keeping the boundary references ARCH-02 and PRIVACY-02 as the sole identifiers cited.

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

• On-device and hybrid routing boundary
• Cove network audit
• Google Play — prominent disclosure and consent guidance
• Google Play — Data safety section
• Android Developers — DataStore in the app data layer

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

Frequently asked questions