Mapping the data lifecycle of a fictional fitness account case

What to take away

"Stride Notes" is a fictional fitness journal. It lets adults record walks, time routes, attach notes, and view weekly summaries. The company is fictional, as are its people, vendors, architecture, policies, dates, and results. The case is educational and is not legal, security, medical, or product advice.

The trigger

A product manager proposes a neighborhood leaderboard. During review, the team realizes its old diagram shows only the account database. It omits device permissions, map services, analytics, support exports, and summary calculations.

The privacy lead pauses the feature and scopes one journey: a person creates an account, records a walk, views a weekly summary, exports it, and later deletes the account.

Inventory by origin

The team creates five lanes:

The team refuses to call the nickname anonymous. The account table can connect it with an email, device events, and routes.

Map the actual route

Engineers trace a workout from phone storage to an application interface, processing service, location provider, main database, analytics stream, weekly-summary job, notification service, customer-support console, export store, and encrypted backup. They compare network logs, configurations, vendor documents, and test-account results.

The FTC's Mobile Health App Interactive Tool is aimed at developers of apps that handle health, fitness, wellness, and related consumer information. It points readers toward potentially relevant U.S. federal rules but expressly does not provide legal advice or guarantee compliance. The fictional team uses it to create questions for counsel, not to declare that one law applies.

Find purpose mismatches

The age-confirmation field stores a full birth date even though the product rule needs only an adult confirmation. A debugging event copies the first line of every note into analytics. The notification provider receives precise route coordinates even though it needs only an event saying the weekly summary is ready.

The team changes the design:

These are fictional design choices, not universal technical or legal requirements.

Separate permission from activity

The test phone shows location permission set to "while using." The map records that as allowed capability. It does not claim the operating system supplied a coordinate at every moment. Engineers then inspect application events to learn when requests occur and whether access stops after recording.

They add a visible recording indicator, an automatic stop check, and a local draft that can be discarded before upload. Tests cover denied permission, interrupted recording, offline use, and background transitions.

Examine derived records

Weekly totals can be recalculated from workouts. The suggested activity pattern is an inference. The team documents its inputs, refresh date, limited purpose, uncertainty, access, and correction path. It removes the inference from support screens because agents do not need it.

The proposed leaderboard uses a public nickname, coarse area, and weekly distance. The review identifies risks of routine exposure, harassment, and singling out in thinly populated areas. Product decides not to launch until it has safer default visibility, minimum group size, clear enrollment, blocking, reporting, and exit behavior.

Design retention and deletion

The fictional schedule uses event-based rules:

The exact periods are intentionally omitted because appropriate and lawful retention depends on purpose, jurisdiction, contracts, disputes, and system design.

For comparison, HHS guidance on de-identifying protected health information explains the Expert Determination and Safe Harbor methods under the U.S. HIPAA Privacy Rule. The fictional team does not claim that its app data is protected health information, that HIPAA applies, or that a general deletion project meets either method.

Test closure

A controlled account is deleted. The test checks the profile, route objects, summaries, analytics identifiers, notification provider, support view, export URL, and search index. A backup manifest proves scheduled expiry rather than immediate physical erasure. One analytics table fails because a renamed field escaped the deletion query.

The issue remains open until engineers backfill deletion, update the data catalog, add a schema-based test, and rerun the case. The notice is revised only after the operational behavior matches the new design.

What the case proves

It proves only that a fictional team used a repeatable method: scope one journey, inventory by origin, trace recipients, challenge necessity, label unknowns, design controls, and test deletion. It does not prove compliance, safety, anonymity, or fitness-app practices outside this scenario.

Common questions

Is fitness information always covered by HIPAA?

No. HIPAA coverage depends on the entity, role, information, and transaction. Other federal or state rules may apply in the United States.

Why keep unknowns in the map?

An unresolved question is safer than a confident guess. It receives an owner, evidence request, and due date.

Does coarse location eliminate privacy risk?

No. Repeated areas, timestamps, small groups, and outside information can still reveal routines or identities.

Why test deletion with a controlled account?

It lets the team trace expected records without exposing another person's data or destroying evidence needed for a real dispute.