VAC is positioned as a fitness and wellness service, not as a medical service. Even so, heart, sleep, body-composition, injury and longitudinal fitness metrics or inferences can reveal physical or mental health and are treated as health and special-category data where applicable.
HealthKit authorization lets the app read selected types and does not authorize transmission to our systems. Under consent “health-local-receipt-v1-2026-07-20”, version 1.0 reads only and never writes to Apple Health. Raw or detailed Health signals and related body, dietary and up-to-six-month trend series are processed and retained on the device. The minimized receipts described below are separate projections and do not contain the raw Health fields.
The B2 application data model keeps only on the device: primary and focus goals; sex, height and current weight used for local training; target weight and body-fat and muscle targets; training days, intensity and experience; manual body measurements and locally entered series; raw Apple Health samples and identifiers; manual workout rows with stable identifier, day and date, type, duration, optional load and calorie values, and explicit manual provenance; macro, hydration, micronutrient and pinned nutrition targets; meal rows with stable identifier, day, name and logging time, calorie, macro, water and per-nutrient values, source, optional recipe link and per-nutrient provenance, confidence and coverage; and day corrections with day, calorie, macro and water values and correction time; custom recipes and meal and recipe favourites and order; long-term goals; private notes, facts and user-authored coaching context; protected progress photos and minimal local metadata; and user-authored local state consumed by the deterministic coach.
For competitions, only a “vac.workout-receipt.v1” receipt may leave the device: a one-way pseudonymous identifier, sport, Europe/Rome civil day, duration rounded down into 5-minute buckets and, when available, distance in 250-metre and energy in 25-kcal buckets. It contains no Health UUID, exact time, heart rate, power, cadence, zones or source. App Attest authenticates the app, device and request and limits replay, but does not certify HealthKit provenance or real-world performance. Manual workout entries stay on the device, are not posted to the workout API and award no IC or GAIN points. Opponents see only necessary competition values or an aggregate result. HealthKit data are not used for advertising or tracking.
For sleep-duration IC, only an envelope with the two keys “receiptSchema” equal to “vac.sleep-receipt.v1” and “receipts” may leave the device. The array contains one to five records and no more than one per Europe/Rome wake day in the latest five days. Each record contains exclusively “wakeDay” and “durationMinutes15”: a duration from 4 to 14 hours rounded down into 15-minute buckets. The server awards 0 to 53 IC from duration alone. The receipt contains no UUID, source, exact time, stages, efficiency, midpoint, quality, consistency or other Health data. VAC does not persist it as a Metric, snapshot or dossier; it retains only the CoinEntry ledger row needed for IC, with amount, reason, a sleep/day reference, account/team/week attribution and creation time. App Attest is mandatory, body-bound through dedicated headers, and limits unauthenticated requests and replay, but does not certify HealthKit provenance, real sleep or sleep quality.
The device keeps the local archive described above under complete file protection and marked for exclusion from system backups on iOS. Progress photos follow the same local protection. Local-only data do not transfer automatically to a new device and may be lost on uninstall, reinstall or device replacement. The only current Health projections reaching the backend are the minimized workout and sleep receipts described above. Backups created before this protection at the iOS system level may contain historical copies; withdrawal or deletion does not retroactively remove them.
The “.vacbackup” file is VAC's encrypted backup-and-restore artifact, not a generic data export. After archive authentication and a complete dry-run, only the localRestorable segment can be restored for the same opaque backup subject; the serverViewOnly segment remains view-only in the server export and never enters a mutation API.
On the first authenticated B12 migration, the client automatically copies to this device only the B2 localRestorable snapshot: profile, primary and focus goals, body inputs and targets, training preferences, nutrition targets, meals and corrections, recipes and favourites, long-term goals, and non-Health-derived private context — the profile note, UserNote records and PinnedFact records. It validates the complete snapshot and commits it locally before acknowledging the migration; only the acknowledgement bound to the snapshot digest permits purge of the matching remote source, and an invalid or over-limit snapshot is rejected rather than silently truncated. After that receipt exists, another device cannot fetch the server snapshot again and needs an authenticated, encrypted, same-subject “.vacbackup” backup to receive this local state. Health-derived legacy data and legacy manual workouts or body measurements outside the migration payload do not become local authority and follow a separate retention or erasure path.