App Shutdown, Data, Subscription, and Device Lock-In Risks in Smart Fitness

Quick answer

Smart fitness lock-in is the gap between what the hardware can do on its own and what depends on an account, paid plan, cloud service, app, supported operating system, proprietary accessory, or continuing manufacturer support.

Before buying, write down the functions you consider essential and classify each one as local, account-dependent, subscription-dependent, internet-dependent, device-dependent, or service-dependent. Then verify what remains if you cancel, pause, delete the account, lose internet access, replace the phone or tablet, buy the equipment used, or the provider migrates or retires a service.

Do not treat a current feature list as a support-duration promise. Do not assume cancellation, deletion, data export, hardware reset, and service shutdown are the same event. A valid result may be that the equipment retains an acceptable basic mode, that it remains useful only with named conditions, or that the unresolved downside is large enough to justify another product or no purchase.

Scope and authoritative boundary

This guide addresses connected-fitness continuity risk in the United States. It covers accounts, subscriptions, software updates, operating-system support, cloud data, data export, account deletion, proprietary accessories, used-device transfer, service migration, and platform shutdown.

It does not determine whether a product fits a room, whether a subscription is good value, whether one platform has better classes, whether a device is medically suitable, or whether a company is financially likely to fail. Those are different questions with different evidence needs.

The source order used here is:

the current exact product and membership records;
current service, account, privacy, cancellation, export, transfer, and support records;
current app-store and device-support records;
official transition or retirement notices for historical examples; and
the FTC’s consumer guidance on software-support duration and subscription recordkeeping.

For the separate site-level floor, power, and clearance questions, use Floor Protection, Power, Clearance, and Safety Checks for Home Fitness Equipment. This does not turn a continuity record into a safety or electrical certification.

For a device-specific app and account identity record, use the separate WalkingPad app-compatibility guide; this page does not turn that compatibility record into a continuity guarantee. Official documentation is still not an observed continuity test. Official support is not observed continuity.

Distinctness from Articles 37, 38, and 40

Article 37 owns current platform functions, compatible devices, connection direction, metrics, control, and export claims; use the JRNY, Peloton App, and Zwift compatibility comparison for that platform-function question. Article 38 owns disclosed recurring-cost scenarios; its subscription-versus-no-subscription cost framework is a separate cost question. Article 40 owns the smart-system-versus-modular-equipment format decision.

This page owns the downside question:

The same source may appear in more than one article, but the conclusion must remain attached to the question that article owns.

The lock-in record

Create one dated record for one exact product-and-service path. Do not write “Peloton,” “JRNY,” “Tonal,” or “Zwift” as if each name described one permanent product.

Field	What to record	Why it matters
Hardware	Exact product, generation, screen, controller, serial or device identifier when relevant	Similar retail names can have different support paths
Market and region	Country, store region, account region, currency, and seller	Features, plans, privacy routes, and device support can differ
Service identity	Exact app, platform, membership tier, and checked date	A free account, app plan, and connected-equipment plan are not interchangeable
Billing channel	Direct, Apple, Google, retailer, employer, or another channel	Cancellation, pause, refund, and renewal paths can differ
Required functions	The exact content, metric, control, history, profile, or export you need	“Works” is too broad to audit
Local fallback	What the hardware does without a paid plan, internet, account, or current app	This bounds post-cancellation usefulness
Data state	What is stored locally, in the provider account, or in another platform	Cancellation and deletion can affect different records
Export path	Exact file or request route, scope, timing, and limitations	Sync is not necessarily portable data
Device dependency	Required phone, tablet, TV, touchscreen, operating system, and version	Hardware may outlast a supported display device
Accessory dependency	Proprietary controller, sensor, screen, handle, adapter, or service part	An accessory can become the control bottleneck
Transfer and reset	Used-device, household, rental, reset, activation, and ownership rules	A powered-on device may still be untransferable
Change triggers	Price, terms, app version, OS support, acquisition, migration, retirement, or shutdown	A dated recheck is part of the decision

A complete record does not guarantee continuity. It shows which dependencies are known and which decisions remain blocked.

Outcome labels used in this guide

Outcome	Meaning
Documentation supports further diligence	The exact dependency and current fallback are documented well enough to continue
Eligible only with named conditions	The product may remain in consideration only if the listed account, service, device, or fallback conditions are acceptable
Provider confirmation required	A material behavior is not resolved in current public records
Export or evidence preservation required first	The next account or subscription action could make records harder to retrieve
Service-continuity risk is unresolved	The buyer’s essential function depends on an unbounded or unsupported future state
No purchase or defer	The downside cannot be bounded before payment, activation, deletion, or transfer

These are evidence states, not predictions about company survival or product quality.

Risk class 1: platform, product, region, and plan identity

Lock-in analysis begins with identity. A product name can cover multiple hardware generations. A platform name can cover free accounts, app-only memberships, connected-equipment memberships, business plans, legacy entitlements, and regional variants.

Record the exact tier and the exact hardware or app surface that receives the feature. For example, a mobile-app benefit does not establish that the same app runs on a built-in touchscreen. A connected-equipment membership does not establish that an app-only plan provides the same profiles, metrics, or hardware control.

If the provider page does not bind a function to the exact plan and device, keep the function unresolved.

Risk class 2: required, optional, and bundled subscriptions

Classify the paid plan as:

mandatory for initial activation;
mandatory for the essential function;
optional for content or coaching;
bundled for a limited period;
included only with an eligible product or serial;
required for a proprietary accessory; or
not required for the buyer’s defined task.

A free trial does not establish the post-trial state. A complimentary plan tied to a serial or promotion does not establish lifetime eligibility. The FTC subscription guide recommends checking the trial, auto-renewal, cancellation, and expected renewal amount and preserving cancellation records.

Risk class 3: post-cancellation hardware fallback

Ask what the equipment can do after the paid plan ends:

Can resistance or load still be adjusted?
Can the equipment start without logging in?
Does a local workout mode remain?
Are safety controls still available?
Are history, programs, recommendations, or custom workouts unavailable?
Is internet still required for firmware or startup?
Does the screen remain usable for anything beyond a limited mode?

Basic fallback is not feature parity. A product that retains a manual mode may still lose the function that justified its purchase price.

Risk class 4: accounts, profiles, and household access

Record which account owns the device, membership, workout history, payment method, profiles, and connected services. Check whether one membership can be active on multiple machines, whether profiles are individual or shared, and whether removing the household account affects all users.

A household profile is not necessarily an independently transferable account. A purchaser should not assume that a family member can keep data or access after the membership holder closes the account.

Risk class 5: workout history, progress, and cloud data

Separate these objects:

account profile;
completed-workout history;
achievements and progress scores;
custom workouts;
favorites and programs;
health-platform copies;
raw activity files;
support and purchase records.

A provider may preserve some history after cancellation while blocking new tracking. Another may delete workout history when the account is deleted. Record each disposition rather than using one field called “data.”

Risk class 6: export, sync, deletion, and portability

An export route should name the file or data scope, the request method, and whether it remains available after cancellation. Health-platform sync is not a complete raw-data export. A summary copied to another app may omit intervals, device state, resistance, calibration, or proprietary scores.

Subscription cancellation is not account deletion. Account deletion is not subscription cancellation. One may stop billing while preserving the account; the other may remove workouts, achievements, profiles, or access. Do not delete an account until the buyer has saved the records that matter and understands the current retention language.

Risk class 7: internet, firmware, and software updates

Record whether the hardware requires internet for activation, login, workout start, content, metrics, control, history, firmware, or safety-related updates. Then ask how long updates are promised.

The FTC notes that smart-device usefulness can change when software support ends and advises checking how long updates will continue and what the product does afterward. A feature available today is not a support-duration guarantee.

If the provider does not publish a support horizon for the exact device, record the horizon as unknown rather than “lifetime.”

Risk class 8: phone, tablet, TV, and operating-system support

Connected hardware can remain mechanically intact while its required display or companion device becomes unsupported. Record:

minimum operating system;
app-store region;
required processor or device class;
built-in touchscreen generation;
whether web, phone, tablet, TV, or another device is accepted;
whether the current hardware can receive future app versions; and
what remains when the app no longer installs.

A current minimum version is a dated compatibility field, not a promise that an old phone or screen will continue to work.

For a bike-specific compatibility and device-support record, use the separate Peloton App compatibility guide. This page keeps the broader lock-in question separate from that platform-specific compatibility result.

Risk class 9: proprietary accessories and control paths

A connected product may rely on a proprietary screen, controller, handle, sensor, adapter, mount, or installer. Record whether the accessory:

works only with one service;
requires an active membership;
uses an open or proprietary protocol;
can be replaced from a current parts route;
retains a local function if the service ends; and
can be used by another app.

An open protocol may reduce one dependency, but it does not guarantee future support. A proprietary accessory may work well today while concentrating failure and service risk.

Risk class 10: used-device transfer, reset, and activation

A used connected device needs more than a power-on demonstration. Verify proof of ownership, rental or finance status, prior-account removal, factory reset, screen generation, activation fee, membership commitment, installation history, warranty transfer, and current support eligibility.

A seller’s active login does not establish that the buyer can activate the hardware. A reset does not establish that cloud restrictions, rental status, serial blocks, or old-screen support have been resolved.

Risk class 11: renewal, cancellation, pause, and refunds

Record the billing channel before joining. Direct, Apple, Google, employer, or partner billing can have different cancellation and pause routes.

Capture:

initial commitment;
renewal period;
then-current rate language;
trial conversion date;
pause eligibility;
refund rule;
cancellation effective date;
what happens through the paid period; and
confirmation evidence.

Current price is not a future renewal guarantee. Cancellation confirmation should be preserved with account and payment records.

Risk class 12: service migration, shutdown, and company continuity

A service can change without disappearing completely. It may:

migrate content to another provider;
stop selling hardware while continuing support;
retire one app but keep another;
discontinue an app-only plan;
reduce supported devices;
move billing or account systems;
close a connected service while hardware retains local functions; or
end with no equivalent fallback.

A service migration is not the same as an unchanged product experience. A historical transition shows a possible risk class, not a forecast for another company.

Build the pre-purchase continuity record

Complete the record before the return window or minimum membership commitment starts. Store a dated PDF or screenshot only when permitted and useful, plus the URL, plan, region, hardware identity, and checked date.

The record should answer:

Which functions justify the purchase?
Which dependencies are mandatory for each function?
What is the documented local fallback?
What data must be preserved before a change?
What device or accessory can become unsupported?
What transfer or resale path exists?
Which unresolved item would cause no purchase or defer?

Identify every required account and billing channel

List the equipment account, membership account, app-store account, health-platform account, streaming account, and household profiles separately. A single email address can still be attached to multiple contracts and deletion consequences.

Record where cancellation must occur. A subscription purchased through an app store may not be cancellable through the equipment provider. Conversely, deleting the mobile app does not cancel the subscription.

Separate local functions from cloud functions

For every essential function, label it:

Local hardware
Local software on the device
Account-authenticated
Cloud-computed
Subscription-gated
Internet-streamed
Phone/tablet dependent
Proprietary-accessory dependent
Unknown

A function can occupy more than one category. For example, a local resistance motor may remain available while automatic programming, progress tracking, and classes require cloud and membership access.

Record what works without a paid membership

Do not accept “works without subscription” without a function list. Verify whether the post-cancellation state includes:

equipment startup;
manual load or resistance;
emergency or safety controls;
local metrics;
guest mode;
saved profiles;
historical data;
firmware updates;
custom workouts;
third-party app connection; and
support eligibility.

A limited mode may be adequate for one buyer and unacceptable for another.

Record what stops when membership ends

Name the lost functions precisely. Common categories include class library, adaptive load, automatic resistance, personalized recommendations, dynamic modes, progress scores, custom-program storage, profile capacity, entertainment apps, data history, and multi-device activation.

Do not convert one provider’s post-cancellation behavior into a category rule.

Record what happens to historical data

Ask whether history remains viewable after cancellation, whether new workouts are recorded, whether a free account is required, and whether data disappears after account deletion.

Capture the current route before changing the account. If the answer is not published, contact the provider and preserve the response, but do not represent a private response as a universal public policy.

Find a real export path before relying on portability

“Syncs with” is not enough. A useful export record identifies:

the exact data scope;
file type or API;
download or request path;
whether export includes historical data;
whether it requires an active membership;
expected processing time;
missing proprietary fields; and
importability elsewhere.

If the platform provides no same-scope export, the portability result remains unknown or limited.

Separate account deletion from data retention

Read the current privacy and deletion records before submitting a request. Providers may retain some records for legal, fraud, financial, security, or support reasons even when the user-facing account is deleted.

This guide does not interpret privacy law. It records the provider’s current process and the functions or records the buyer could lose.

Check update duration and end-of-support disclosure

Search the product page, support site, app listing, terms, and security/update policy for a support horizon. Record whether the horizon applies to the exact hardware, screen, app, or operating system.

When no duration is disclosed, the correct field is:

Software-support duration: unknown

Do not replace it with the warranty period. Hardware warranty and software-support duration answer different questions.

Check current device and operating-system requirements

Record the minimum versions on the checked date and test the buyer’s actual device before the return window closes. Recheck after a major app update.

A provider may announce a future minimum-version increase. Treat the effective date as a separate state from the current state, and identify the fallback if the buyer’s device no longer qualifies.

Check proprietary controllers, sensors, and accessories

Ask whether the essential feature still works if a controller or sensor fails, becomes unavailable, or loses app support. Verify whether a generic replacement exists and whether the product can be controlled without the accessory.

A controller marketed for one platform should not be assumed to work with another merely because both use Bluetooth.

Check used-device and household transfer rules

Before payment, verify:

ownership and rental status;
previous-account removal;
serial or device-status check;
factory-reset process;
activation fee;
remaining commitment;
membership transferability;
warranty transferability;
screen or controller generation;
local fallback after reset; and
current provider support for the secondhand path.

If the seller cannot establish ownership or the provider cannot resolve activation, do not pay based on a successful demo under the seller’s account.

Check the cancellation path before payment

Locate the exact cancellation route for the billing channel and note the effective date. Record whether pause is available, whether a trial converts automatically, and whether the plan renews at the then-current rate.

Save the order, trial, membership terms, cancellation request, and confirmation. The FTC recommends keeping cancellation records and monitoring statements after cancellation.

Save evidence before deleting or closing an account

Before deletion:

cancel or pause the correct subscription when required;
download available files and receipts;
capture profile and device identifiers;
remove third-party connections where appropriate;
understand household consequences;
verify local hardware fallback; and
preserve the deletion confirmation.

Deletion can be irreversible. Do not use it as a troubleshooting step when reset, profile removal, or billing cancellation is the intended action.

Tonal 2 and Tonal membership example

Current Tonal membership documentation states that the first 12 months are required. After that period, cancellation leaves Basic Lift, weight adjustment, supported safety controls, and Wi-Fi settings for updates, while membership intelligence, personalization, dynamic modes, tracking, custom workouts, and the workout library are unavailable.

Current Tonal Terms also state that an internet connection is always required to use the Product and Service, even without an active paid subscription. This makes network and continuing-service dependency separate from the membership payment state.

This example demonstrates a documented basic fallback, not feature parity. Historical workout visibility, new-workout recording, account deletion, installation history, used-device support, and multi-Tonal activation are separate fields that require their own current records.

Peloton Bike and All-Access example

Current Peloton Terms of Service define the Peloton Service across equipment tablets, apps, websites, studios, and service content. Cancellation or account changes therefore need separate checks for hardware-local use, classes, metrics, profiles, achievements, user content, device generation, and privacy requests.

Current Peloton used-bike guidance also illustrates transfer-specific dependencies: proof of ownership, rental status, activation, touchscreen generation, non-transferable base warranty, and current feature-update support. A working seller account does not prove a buyer can activate the same device.

BowFlex VeloCore and JRNY example

The current JRNY platform page distinguishes full membership experiences from limited or essential content paths. Exact behavior depends on the product, built-in screen, mobile device, membership tier, billing channel, region, app version, and current support record.

The continuity record should separate resistance hardware, local console functions, JRNY classes, adaptive features, entertainment streaming, profiles, workout history, third-party app connections, and post-membership behavior. Current JRNY Terms of Use also separate direct service terms from third-party app-platform terms, while the JRNY Refund Policy treats monthly and annual cancellation/refund states differently. Do not transfer a fallback documented for one BowFlex generation to another.

Zwift, third-party hardware, and Zwift Play example

Current Zwift membership guidance separates cancellation, paid-period access, and permanent account deletion. Zwift also provides activity-file routes, but export scope and timing should be verified before account deletion.

Current supported-device guidance shows that operating-system minimums change over time. Zwift Play is a proprietary controller path tied to Zwift account, membership, app, and supported hardware. A third-party trainer may retain a local or another-app mode, while the controller’s value can be more service-bound.

lululemon Studio Mirror transition example

The official lululemon and Peloton partnership announcement documented a service transition: lululemon stopped selling Studio Mirror hardware and planned Peloton as the exclusive digital content provider, while describing continued support for existing Mirror members and warranty obligations.

This historical example shows why “shutdown” should not be one binary field. Hardware sales, app-only membership, content provider, existing-member access, technical support, and warranty support can move on different timelines. A service migration is not the same as an unchanged product experience.

Wahoo RGT retirement example

Wahoo’s official current, discontinued, and obsolete product list identifies Wahoo RGT as obsolete software. That historical state demonstrates an actual service-retirement class.

It does not establish what will happen to another platform. The buyer must still ask whether hardware works in another app, whether activity files were exportable, whether accounts or subscriptions required action, and whether proprietary accessories retained another use.

Scenario: buyer wants the hardware to work without subscription

Required record:

Essential local functions
Initial mandatory commitment
Post-cancellation startup
Manual control
Safety controls
Local metrics
Internet requirement
Firmware/update path
Account requirement

If only a marketing phrase such as “subscription optional” is available, the result remains conditional. The exact fallback function list decides whether the product fits the buyer’s requirement.

Scenario: buyer needs downloadable workout files

A health-platform summary is insufficient. The buyer needs a documented file or data-request path, scope, timing, and post-cancellation availability.

Zwift’s activity-file route can remain a candidate for this requirement. A platform with only dashboard history or health sync remains unresolved for same-scope portability until a real export path is documented.

Scenario: buyer expects one household account to cover multiple devices

Record profile count, simultaneous-device rule, equipment activation limit, residence rule, and whether another membership is required for concurrent use.

A platform may allow several profiles but only one active machine, or may support one membership holder while other household members depend on that account. If the buyer needs independent ownership and histories, the shared-account model may not fit.

Scenario: buyer uses an older tablet or touchscreen

Check the current app minimum and the exact built-in screen generation. If the provider has announced a higher future minimum, record both dates.

If the old device cannot install the current app and the hardware has no acceptable local fallback, the buyer should change the device plan or defer the purchase. A warranty that remains active does not guarantee current app support.

Scenario: buyer buys a used connected device

A used purchase requires proof of ownership, account release, rental or finance status, reset, activation, screen/controller generation, current software support, membership commitment, installation history, and fallback mode. The broader used-equipment inspection and ownership-risk guide and the warranty, return, service, and repairability matrix provide separate transaction and policy records; neither substitutes for the exact platform confirmation required here.

If the provider cannot confirm eligibility or the seller will not remove the account, the correct outcome is no purchase or defer.

Scenario: buyer wants to delete the account but keep local hardware use

The buyer must confirm that local use remains after deletion, not merely after subscription cancellation. Some products may need an account for startup, ownership, updates, or support even when a paid plan is absent.

Export the necessary records, verify device state, and distinguish profile deletion, account deletion, factory reset, and membership cancellation before proceeding.

Scenario: required service has no published support horizon

The buyer cannot calculate a guaranteed service life. Record the support duration as unknown and ask:

Is there a useful local mode?
Can another app control the hardware?
Is the accessory proprietary?
Can data be exported?
Is the buyer paying a premium mainly for cloud functions?
Is no purchase or defer acceptable?

Unknown is not a pass, zero, or guarantee.

Scenario: platform migrates rather than fully shuts down

Map each component separately:

Hardware sales
Existing-member access
New memberships
Content provider
App availability
Account migration
Historical data
Support
Warranty
Accessories

A migrated content library may preserve some use while changing instructors, programs, metrics, billing, profiles, devices, or data. Do not label the experience “unchanged” without same-scope evidence.

When manufacturer confirmation is required

Seek current written confirmation when the public records do not resolve:

exact post-cancellation functions;
account deletion and local use;
secondhand activation;
remaining membership commitment;
proprietary accessory fallback;
data export scope;
old-screen or OS support;
concurrent-device limits; or
announced service transition timing.

A private response applies to the exact question and date. It does not become a universal policy for all readers.

When a data export should happen before cancellation

Export before cancellation or deletion when:

the export route requires active membership;
the account contains long-term history;
the buyer needs receipts, serials, or support records;
a service transition is announced;
a device is being sold or transferred;
another platform will receive the data; or
the provider does not state whether access continues afterward.

Verify the downloaded files before closing the account.

When a replacement device or open-standard path is worth considering

A phone, tablet, screen, sensor, trainer, or controller that uses a broadly supported protocol may reduce one dependency, but only if the exact essential function is available through the alternate path.

Do not assume “Bluetooth,” “FTMS,” or “ANT+” means every metric, control direction, or app is supported. The alternative must be tested or documented for the exact hardware, firmware, service, and desired function.

Stop conditions

Stop the purchase, transfer, cancellation, deletion, or reset when:

exact hardware or plan identity is unresolved;
the essential function has no documented fallback;
the service-support duration is material and undisclosed;
the buyer cannot export needed data;
the prior owner cannot release or prove ownership;
rental, finance, serial, or activation status is unresolved;
the required phone, tablet, TV, or screen is unsupported;
a proprietary accessory is unavailable and no alternate control exists;
account deletion consequences are unclear;
cancellation channel or continuing commitment is unresolved; or
a service transition has no clear path for the buyer’s exact account and hardware.

Prohibited inferences

Do not infer:

Current feature = permanent feature
Warranty period = software-support period
Subscription optional = account optional
Cancellation = deletion
Deletion = immediate deletion of every retained record
Health sync = raw-data export
Bluetooth = universal compatibility
FTMS = every metric and automatic control
Local mode = full paid-feature parity
Provider support page = observed long-term support
Open protocol = guaranteed future support
Used device powers on = buyer can activate it
Service migration = unchanged experience
No shutdown announcement = future continuity guarantee

Fallback paths

A bounded fallback may include:

documented local manual mode;
a free account with an acceptable function set;
export before cancellation;
a supported third-party app;
replacement of the phone or display device;
non-proprietary sensors or controllers;
modular equipment with no required cloud service;
official refurbished or supported secondhand path; or
no purchase or defer.

The fallback must satisfy the buyer’s essential function, not merely keep the equipment powered on.

No purchase or defer

No purchase or defer is appropriate when the buyer is paying primarily for a connected function whose duration, fallback, transferability, or data path cannot be bounded before purchase.

It is also appropriate when a used device cannot be released from a prior account, a required proprietary accessory is unavailable, the buyer’s only device is unsupported, or deletion/cancellation consequences cannot be resolved before an irreversible action.

Missing and conflicting inputs

Keep these as explicit unknowns when they are not published for the exact path:

Software-support end date
Post-cancellation function list
Account-free startup
Offline behavior
Firmware behavior after cancellation
Raw-data export scope
Deletion and retention timing
Profile and simultaneous-device limits
Used-device activation eligibility
Proprietary-accessory replacement
Migration timeline
Historical-data disposition
Support after company or service transition
Future renewal price

Do not average or silently reconcile conflicting terms. Record the plan, region, page, effective date, and billing channel for each source.

Save the lock-in record

Preserve:

product and device identifiers;
plan and billing channel;
feature/fallback matrix;
subscription and cancellation terms;
export files and receipts;
account/deletion records;
current OS and app requirements;
transfer and reset requirements;
source URLs and checked dates;
provider confirmation when used; and
next recheck trigger.

Material triggers include price or plan change, app update, OS update, new device generation, acquisition, discontinued hardware, service migration, shutdown announcement, and used-device transfer.

Recommendation boundary

This documentation does not establish which smart-fitness platform, product, subscription, or hardware format is best. It does not predict whether a company will continue operating, whether support will be timely, whether data will remain recoverable, or whether a current fallback will satisfy a future user.

A recommendation requires the buyer’s essential functions, acceptable fallback, account and data needs, device plan, cost scenario, support horizon tolerance, and current exact records. Where those inputs are incomplete, the recommendation is withheld.

Next step

For one exact product, complete the lock-in record before checkout or before changing the account. Verify the current plan, billing channel, local fallback, export route, device requirements, transfer/reset path, and cancellation/deletion consequences.

If the product remains eligible, recheck the same records during the return window and before any irreversible cancellation, account deletion, reset, resale, or service migration.

Methodology

The canonical review used the official product, membership, account, privacy, device-support, and transition records in the 2026-07-28 source snapshot, plus a 2026-09-14 recheck of the same eighteen accepted routes for current identity, availability, redirects, HTTP/transport, and material wording changes. It also used FTC consumer guidance to define software-support and subscription-record questions. The recheck does not add a source, direct test, account transaction, or continuity guarantee.

The platform sample is explicit, bounded, and non-exhaustive. It contains current Tonal, Peloton, JRNY/BowFlex, and Zwift paths plus two historical transition/retirement examples: lululemon Studio Mirror and Wahoo RGT. Current and historical examples are not pooled into a failure rate and are not ranked.

For every claim, the method separates current function from future support, cancellation from deletion, sync from export, local fallback from feature parity, current device support from support duration, and service migration from unchanged use. Missing fields remain unknown. No direct test, account transaction, subscription transaction, export, deletion, transfer, or shutdown observation was performed.