Consent-first bandwidth monetization rollout

A consent-first implementation makes the user’s decision an enforceable runtime boundary. The application explains the feature and chooses when to offer it; the SDK owns the consent window, validates the resulting receipt, and exposes a state the application can observe.

That division is important. If an application recreates the flow with a local boolean or treats a dismissed window as acceptance, the displayed product state can diverge from the state enforced by the SDK.

Separate offer, decision, and operation

There are three distinct moments in the user journey:

1. Offer: the application explains why the feature is available and what the user receives.
2. Decision: the SDK-owned flow records accepted, declined, or cancelled.
3. Operation: an accepted SDK instance connects and later reports online or offline state.

The return from connect() is not proof that the peer is online. It starts an asynchronous supervisor. Product UI should move to an online state only after the connected event or equivalent wrapper observation.

This separation also keeps consent independent from temporary network availability. A disconnected accepted instance can reconnect; a revoked instance cannot be treated as merely offline.

Preserve all decision outcomes

Decline and cancel are legitimate outcomes. They must leave the application usable without constructing an SDK instance or repeatedly presenting the flow in a coercive way.

Acceptance produces an instance only after receipt verification. The application should retain the instance under one owner and avoid copying receipt data into analytics or logs. The exact wrapper behavior is documented in Consent and revoke.

Revocation should be accessible after acceptance. When the remote revoke succeeds, the wrapper marks the local decision revoked and closes the active instance. If the remote operation fails, the existing decision remains intact so the user can retry. UI must not claim success before that transition completes.

Make data boundaries explicit

The public integration contract distinguishes application data from the network peer lifecycle. Application code supplies approved configuration and reacts to lifecycle events; it does not configure service discovery credentials, transport secrets, or reconnect policy.

Operational logging should focus on events that help diagnose lifecycle behavior:

• consent outcome without copying receipt contents;
• instance creation and final release;
• connected and disconnected transitions;
• stable error codes and sanitized context;
• application and SDK versions required for support.

API keys, credentials, receipt material, access tokens, proxy passwords, and user-provided content do not belong in a support bundle. The security and data guide and observability guide define the public boundaries.

Test the transitions, not only the happy path

A production candidate should demonstrate the complete state machine on every supported platform:

Transition	Expected evidence
Fresh install → decline	No SDK instance and no network peer activity
Fresh install → accept	Verified decision and one owned instance
Connect → online	Online state only after the connected event
Network loss → recovery	Disconnected reason followed by supervised reconnection
Accepted → revoke	Remote success, local revoked state, instance closed
Shutdown	No callback or SDK call after final release

Background execution, operating-system suspension, and process shutdown differ by platform. Use the matching platform guide rather than transferring lifecycle assumptions between Android, iOS, desktop, and server hosts.

Roll out with clear stop conditions

Start with internal and controlled test populations. A rollout stage should have defined evidence for consent completion, connection stability, revoke success, resource impact, and support quality. Expansion should stop when a platform shows unexplained lifecycle failures or when the user-facing controls do not match the enforced SDK state.

The goal is not to maximize acceptance. It is to make every accepted decision informed, verifiable, reversible, and technically safe. Continue with the testing guide and production checklist before release.