privacy@getsvaya.com

1. Who we are

Svaya is operated by Vyoma Technologies Limited (“Vyoma”, “we”, “us”). Svaya™ is our trademark. A US trademark application for SVAYA is pending on the Principal Register — US serial number 50018265, filed 28 July 2026 on an intent-to-use basis under § 1(b), in International Class 009. It is not yet registered, which is why the mark appears as ™ throughout and never as ®.

• Registered office: 3296 Logsdon Loop, Delaware, Ohio 43015, USA

• Privacy and data-rights contact: privacy@getsvaya.com

• General contact: hello@vyomatechnologies.com

• India grievance officer: Grievance Officer, Vyoma Technologies Limited — support@getsvaya.com, 3296 Logsdon Loop, Delaware, Ohio 43015, USA — see §11.

For users in the European Economic Area and the United Kingdom, Vyoma is the controller of the personal data described here.

*RESOLVED 2026-09-04. This paragraph previously recorded a conflict: the app and the served page carried the pre-rename @fitcoach.app address while this policy directed data-rights requests elsewhere, and only one could be the address of record. The founder has confirmed the three live mailboxes — privacy@getsvaya.com for privacy and data-rights requests, support@getsvaya.com for support, and hello@vyomatechnologies.com for corporate and legal notices — and every @fitcoach.app route has been removed from the document set, from the served pages and from the app. Verified 2026-09-04: 13 references in the iOS source and 13 in the served pages resolve to privacy@getsvaya.com, and no @fitcoach.app mailbox remains in either. The App Store listing is the one surface not verifiable from the repository and must be checked before launch.*

2. The short version

1. Raw camera video is processed on your phone and is not uploaded during a workout. Verified: no image, frame, or video column exists on workout_frames; the table stores only numeric geometry.

2. The body-geometry data computed from that video IS uploaded and stored on our servers, and it is the core of how Svaya works. It is not optional, and it is not anonymous.

3. That geometry includes points on your face — nose, both eyes, both ears — and, when your device uses the high-resolution capture mode, your jaw, chin, eyelids, eyeballs, and every joint of all ten fingers.

4. We train our own models on it, but only if you switch that on. Model training is a separate opt-in, default off, and revocable.

5. We never sell your data, never give it to advertisers or data brokers, and never give it to another company to train their models.

6. You can export everything and delete your account from inside the app.

Everything below is the detail behind those six lines.

3. What we collect

3.1 Account and identity

Data Notes
Email address Stored hash is stored for l	encrypted at rest; a separate one-way ookup
Display name
Password Stored only form	as a salted hash, never in readable
Sign in with Apple I identifier	f you use Apple sign-in
Two-factor secret En	crypted, only if you enable 2FA
Login and lockout Ti history state	mestamps, failed-attempt counts, account-lock

Verified: users table columns email, email_hash, password_hash, password_hash_algo, apple_user_id, totp_secret_enc, failed_login_attempts, locked_until, last_login_at.

3.2 What you tell us about your body and your health

Data Notes
Age, gender, height, weight, body type F	rom onboarding and Settings
Fitness level, training experience, training frequency, time since last break
Goals, target state, sessions per week, session length
Equipment you own, and the locations you train in
Body measurements you log over time
Health conditions and injuries you Inc select or type cardiac conditions and pregnancy	ludes categories such as

Verified: user_profiles (24 columns incl. age, gender, height_cm, weight_kg, body_type, primary_goal), body_measurements, user_health_conditions, user_equipment, user_locations, user_goals.

Health conditions and injuries are sensitive data. They are treated as special-category data under GDPR Article 9, as sensitive personal data under India's DPDP framework, and as consumer health data under Washington's My Health My Data Act.

3.3 Body-geometry ("pose") data — read this section

This is the significant one, and it is the reason this policy exists in this form.

What happens. During a tracked set, your phone runs a pose-estimation model on the live camera feed on the device. The model outputs the coordinates of a set of named body points. Those coordinates — not the picture — are uploaded to us and stored, at roughly fifteen samples per second.

What is in each stored sample:

• Named body points, each with a horizontal and vertical coordinate and a confidence value. Some capture modes additionally record a depth coordinate and a three-dimensional world position for each point.

• Computed joint angles — currently 21 named values, including both elbows, both shoulders, both hips, both knees, mid-spine, and a family of movement-specific depth metrics.

• The rep-counter signal, the detected movement phase, the running rep count, the set number, and a form score.

• Camera quality metadata: confidence, tracking quality, pitch and roll angle of the phone, and whether the phone was steady.

• Which pose engine produced the sample.

Verified: workout_frames columns landmarks (jsonb), joint_angles (jsonb), depth_metric, depth_metric_key, rep_count, phase, set_number, form_score, form_events, camera_confidence, tracking_quality, camera_pitch_deg, camera_roll_deg, camera_steady, primary_source, counter_source, counter_depth, rep_event, in_position. Per-point keys observed across the corpus: name, x, y, conf, z, wx, wy, wz.

How many points, and which ones. Measured across the 467,865 samples currently stored:

Skeleton Points	Samples **W	hen collected*	*
Standard (current 23 behaviour) (95.8%) ongoi	448,203 2026-0 ng	4-19 → today,
High-resolution ARKit only	112–113** 8,88	6 (1.9%) **202	6-08-01 → 2026-08-03
Partial / 8–30 10,776 ( low-confidence	2.3%) throughou	t

The standard 23-point skeleton includes five points on your head: nose, leftEye, rightEye, leftEar, rightEar. The remaining eighteen are shoulders, elbows, wrists, hips, knees, ankles, heels, toes, neck and a root point. This is what we collect today, on every tracked set.

During a three-day period in August 2026, a high-resolution capture mode additionally recorded the jaw, the chin, both eyeballs, and the upper and lower lid of each eye — and a complete hand skeleton for both hands: thumb, index, middle, ring and little finger, three to four joints each. That mode is not in use today, but the data it produced is still stored and will remain until it ages out under the 180-day rule in §8. We disclose it rather than describe only the present.

Verified: distinct landmarks[].name values and per-shape date ranges queried directly from workout_frames on 2026-08-16.

This is stated so precisely because it is the fact that decides how this data is regulated. A "stick figure" framing would be inaccurate: a time-series of eye, ear and nose positions is a geometric description of your face, and the August captures add hand geometry — which Illinois' statute names explicitly. See §4.

What is NOT in it. No image data. No video. No audio. There is no pixel, image, thumbnail, or frame column on workout_frames, and none of the stored values reconstruct a picture of you.

Why we store it (legal basis). To count your reps, score your form, drive range-of-motion and tempo feedback, keep your history consistent across devices, and let a coach you have connected review your movement. For users in the EEA/UK this is Article 6(1)(b), performance of the contract you signed up for — the same basis as storing your rep counts. It is not gated behind a toggle, and we do not offer a version of the tracked-workout feature that does not upload it. If you do not want body-geometry data stored, do not run a tracked set; manual logging does not produce it.

Model training is separate and opt-in. See §5.

3.4 Wearables, Apple Health, and motion sensors

If you grant access, Svaya reads the following from Apple HealthKit: heart rate, heart-rate variability, resting heart rate, active energy, VO₂ max, step count, body mass, and sleep analysis. It writes back only your completed workouts and active energy. It never writes your weight.

Verified:; com.apple.developer.healthkit entitlement in iOS/FitCoach/App/FitCoach.entitlements.

What reaches our servers, corrected as of 2026-08-17

wearable reaches our servers, and gave the measurement behind it: zero non-null workout_frames.watch_accel, zero non-null workout_frames.airpods_attitude, zero non-null workout_sessions.avg_heart_rate_bpm, and zero rows in health_metrics and apple_health_workouts, across 467,865 samples and 580 sessions. That measurement was correct on 2026-08-16 and is no longer the current behaviour. Two changes landed on 2026-08-16/17 and this policy states them rather than inheriting the older sentence:

Heart rate is now stored (V90.106). Your watch already ran a real workout session and read heart rate; the app threw every sample away and kept a single overwritten number that was never persisted. It is now stored as a raw timestamped series — one row per reading, roughly one every five seconds — in a dedicated heart_rate_samples table, alongside the app state observed at that moment (which exercise phase was running, and which set number). Those state fields are recorded as contemporaneous facts about the app, not as an attribution of any heartbeat to any set, and heart rate is explicitly barred from grading a set. We store the raw observation and derive the metric later, because heart rate lags the work that caused it and any averaging window chosen before we had data to tune it against would be a guess baked in irreversibly. Verified: migration V111_.

Wrist and head motion can now actually stream (V90.105). The columns had existed since V30 and nothing ever wrote to them, because the watch was told to stop streaming and never told to start — a wiring defect, not a design. That path is now connected, so wrist and head motion can reach our servers. It does so only under the separate opt-in below.

Wrist and head motion (off unless you turn it on)

Only if you turn on Wrist motion in Profile → Data Sharing, we record motion from the devices you are wearing:

Device What we often	record** **How
Apple Watch Accelera rotation rate, and t direction	tion with gravity removed, 50 times a he gravity second
AirPods (models The with motion as a qua support) second	same three, plus head orientation About ternion times a	25

Four things about this that we want to be exact about:

• Only while a set is running. Not between sets, not during rest, not while you are setting up, and never outside a workout.

• Only if the device is actually there. We check for a paired watch and for AirPods that report motion. If they are absent we record that fact and collect nothing.

• Off by default, and nothing breaks without it. Rep counting works from the camera alone and does not use this data. It never has to be there.

• Recording it is not the same as training on it. Whether we may use it to improve our shared models is the separate "Help Train Shared Models" choice. If that is off, this data is not used for training.

We do not record sound, and we do not record your location.

This is stored with the rest of that workout under the same pseudonym, which means it is linkable to your account, not anonymous, and it is deleted when you delete your account.

The two corrections, kept on the record

Corrected 2026-08-16 (V90.105). An earlier version of this policy claimed that head motion from AirPods never leaves the device. That is no longer true, and the sentence was removed rather than softened. If you turn on the wrist-and-head motion setting above, head motion IS sent to our servers. It is off unless you turn it on, and it is only recorded while a set is actually running.

Corrected 2026-08-16 (V90.105). An earlier version of this policy said the watch streamed "raw accelerometer motion" during every workout. That was never true. The database columns built to hold it (workout_frames.watch_accel, workout_frames.airpods_attitude) were non-null on 0 of 470,599 rows — the columns existed and nothing ever wrote to them. The claim was wrong on the day it was written, and V90.105 — which starts collecting this data for the first time, under an explicit opt-in — must not be mistaken for having made the old sentence retroactively correct.

OPEN: a full-rate sensor-upload lane (sensor_sessions) exists in code and ships disabled. It carries a raw user_id, has no training_eligible column, and therefore missed the V34 pseudonymisation sweep, which means consent revocation cannot reach it. It must not be enabled before those two gaps close, and this policy must be re-versioned if it is.

Camera-derived heart-rate estimation

A face-based heart-rate estimation feature (from the camera, not from a wearable) exists in the session pipeline. It is disclosed here for completeness. We use what it produces for your workout summaries and analytics, never for advertising. (Carried forward from Version 2, audit finding #23.)

3.5 Usage and diagnostic telemetry

We record which screens you open, what you tap, how you navigate, errors you hit, and workout events. This is always on; there is no decorative off switch, because we use it to keep the coaching features working and we would rather say so than offer a toggle that does nothing.

It is first-party only — it goes to our own servers under a per-device identifier. It does not go to an advertising network or a third-party analytics product. Verified: analytics_events and crash_reports are our own tables; there is no third-party analytics or advertising SDK in the app.

Because it is keyed to your device rather than your account, the 90-day retention bound in §8 is also what limits it after you delete your account.

3.6 Consent records

Every acceptance, decline and revocation is written to an append-only, hash-chained ledger, together with the SHA-256 fingerprint of the exact text you were shown, the app version, and the time you actually consented.

We keep this even after you delete your account, because it is the record that proves what you were shown and what you agreed to. It contains no personal data beyond your account identifier. Verified: consent_ledger, migration V67. A prior version of this policy also claimed we record the IP address and browser/app identifier observed at consent time; that claim is withdrawn as of 2026-08-19 — the ledger schema has those columns (V96) but the server does not populate them. If capture is ever wired and verified, this section may say so again — not before.

3.7 Video — the cases where it does leave your device

Nothing in (a) to (c) happens during an ordinary tracked workout. Each is something you start deliberately.

(a) Live coaching calls. Your camera and microphone stream in real time to the other participant, via LiveKit (§7). Calls are not recorded — the product has no recording capability and issues no permission that would allow one. Verified: V75_; no media-egress grant path exists.

(b) Coach demonstration clips. If you are a coach, videos you record and upload are stored as files on our server, with a pointer row in the database. Access is only ever through short-lived signed links; there is no public address. Verified:,, V82_.

(c) Group-session recordings a coach uploads.

⚠️ Faces in group-session video are not blurred. Automatic face redaction is designed but not shipped. Today the only protection is the coach's attestation that every person visible agreed to appear and that the coach holds the rights to their likeness. If you appear in a group session, ask your coach what they are uploading.

We state this in the policy rather than only in the coach's upload screen, because the people most affected are the participants — who are not the ones reading that screen. Verified: face redaction exists only in an internal research harness and is not referenced anywhere in the shipping app; the in-app copy at says so directly.

(d) Development builds only — engineering diagnostics. Development builds contain a frame-dump / screen-recording capability used for engineering diagnostics. It is not part of the shipping consumer flow and does not upload media. It will be compiled out of release builds before launch. (Carried forward from Version 2, audit findings #16 and #22.)

3.8 Coaches you connect

If you connect a human coach, they can — only with your explicit per-scope consent — view selected parts of your data, such as your workout history or your body-geometry form replay. Each scope is granted

revoked. Every staff or coach access to your data is written to an audit table (§12). The per-scope consent text is

Version 2 §10, audit finding #21, and expanded to describe the per-scope grant that has since shipped.)*

4. Biometric data — our position, stated plainly

Several U.S. laws regulate "biometric identifiers" specifically, and they do not all define the term the same way.

What we believe the honest characterisation is. The body-geometry data in §3.3 is a repeated geometric measurement of your body, including your face, and in the high-resolution mode your hands. Illinois' Biometric Information Privacy Act names "a scan of hand or face geometry" as a biometric identifier. Texas' CUBI uses similar language. Washington's My Health My Data Act reaches "biometric data" and consumer health data broadly, and covers bodily functions and measurements. We therefore treat this data as biometric, and give you the protections those statutes require, rather than arguing about whether a joint map is technically a "scan".

Accordingly:

(a) We tell you before we collect it. This policy, and the separate body-geometry consent screen

any tracked set can run.

(b) We tell you why, and for how long. Purpose: rep counting, form scoring, progress tracking, and — only with the separate opt-in in §5 — improving our own models. Retention: body-geometry samples are automatically and permanently deleted 180 days after collection. This is not a promise about a future job; it is a database-level retention policy that runs daily. Verified: TimescaleDB retention policy on the workout_frames hypertable, drop_after = 180 days, job 1001, scheduled daily; plus a compression policy at 7 days. Fifty-one retention_sweep events recorded in privacy_events.

(c) We get your written consent. Acceptance is captured electronically with a prior E-SIGN/UETA consent step, recorded in the hash-chained ledger against the fingerprint of the exact text.

(d) We do not sell, lease, trade or otherwise profit from it. Not to anyone, under any arrangement, ever.

(e) We publish our retention and destruction schedule. It is the table in §8.

(f) We protect it. In transit with TLS; at rest on encrypted volumes; stored under a pseudonym identifier rather than directly under your name.

On the pseudonym, honestly. Body-geometry samples are stored against a pseudonym_id rather than your user id. This is a single stable pseudonym per account, not a rotating one, and the samples remain linkable back to you through session identifiers. It reduces casual exposure; it is not de-identification, and we do not describe this data as anonymous. The pseudonym link is severed immediately when you request deletion. Verified: workout_frames.pseudonym_id, ml_pseudonyms table.

5. Training our models

We use body-geometry data, and the "was that rep count right?" corrections you confirm, to train and improve our own rep-counting and form-scoring models.

• The Help Train Shared Models setting controls this. It is off by default.

• Each uploaded sample carries a training_eligible flag set from your setting at the moment of upload. Our training pipeline selects only flagged samples.

• Turning it off stops future samples from being flagged. Samples collected while you were opted in keep their flag; email privacy@getsvaya.com and we will clear them.

• We do not send this data to OpenAI, Anthropic, Google, or any other company for their model training.

• If you delete your account, the "was that rep count right?" corrections you gave us are kept in de-identified form and remain usable for this purpose. They are stripped of every identifier first, and the link back to you is destroyed rather than hidden. §8 describes exactly what is kept and what is not.

Being precise about what the toggle does and does not do. It does not control whether body-geometry data is uploaded — that happens either way, as §3.3 says. It controls only the eligibility flag. We say this plainly because one of our own settings screens currently describes it as though it governed sharing, and that screen is wrong. Verified: the flag is read at and written into the upload payload; the upload itself is unconditional, per the comment at and the runtime log at :1353 ("storage is unconditional"). The setting defaults to false at. Revocation de-flags rather than deletes:, :379-385.

6. Automated decisions and AI

Svaya algorithmically generates your workout plans and prescribes exercises, sets and repetitions. It also produces automated form feedback and projections about how your body may change over time.

• These are software estimates, not professional advice, and they can be wrong. The full statement is in the AI & Automated-Feedback Disclaimer.

• They are not medical advice, not a diagnosis, and not nutritional advice.

• No decision with a legal or similarly significant effect on you is made by automated processing. If you are in the EEA/UK and believe otherwise, you may contact us to request human review.

• To generate plans we send a structured fitness profile to an external AI provider. See §7.

7. Who else processes your data

Processor **What t	hey do** **What they rece	ive**
Microsoft (Azure) Appl database and file §3 storage — one Linux virtual machine that runs our own PostgreSQL/TimescaleDB and holds uploaded fil on its disk. Microsoft supplies the infrastructure; it doe not operate the databa or the application.	ication hosting, Everythi	ng described in
Fly.io Legacy — no traffic. Held all §3 three of the above unt 2026-08-19. The deployment is suspende and its database credential was rotated but a frozen copy of t production database remains there pending destruction.	live A copy of everythin as it stood on il 2026-08-19	g in
Anthropic (Claude Work API) profile — see t below	out-plan generation A str he note	uctured fitness
LiveKit Live video coa sessions video, only w are in a call	ching Real-time audio and hile you
Apple App distribution sign-in, subscription billing, HealthKit	, Per Apple's own terms
GitHub Encrypted off-s database backups — not currently running, see below	ite Nothing since 2026-08	-19
Google ML Kit / Pose e MediaPipe, Apple scori ARKit / Vision, throug CoreML, ONNX Runtime i Google's ML Kit does, by its own declaration collect a device identifier and diagnostic data for it own analytics — see below	stimation, form Your bo ng, coach voice leaves th h these — all nference is local.	dy data never e device
Cloudflare R2 Media st coded but not implemented	orage Nothing today -	–

Where this runs. The application, the database and every uploaded file sit on Microsoft Azure infrastructure in Microsoft's Central US region, in the United States. Until 2026-08-19 all three ran on Fly.io; that deployment is suspended and holds only a frozen copy of the database, which is scheduled for destruction.

Live video does not pass through our servers. When you join a coaching call, your device connects directly to LiveKit's infrastructure over WebRTC. Our backend only issues the signed token that lets you into the room; it never carries the audio or video. Verified:,.

Google ML Kit's own data collection. The pose-detection library we bundle ships a privacy manifest in which Google declares that it collects a device identifier and diagnostic/performance data for its own analytics and app functionality, not linked to your identity and not used for tracking. We do not send it anything and we receive nothing from it, but it is a third-party data flow inside our app and you should know about it. Verified: iOS/Pods/MLKitCommon/Frameworks/MLKitCommon.framework/PrivacyInfo.xcprivacy.

Live video is not recorded. No recording capability exists in the product: the platform issues no media-egress permission for a live session. Verified: live_video_grants / live_video_sessions schema and the absence of any egress grant path.

8. How long we keep things

Data Retention	Enforced by
Body-geometry samples (workout_frames) perman production	*180 days**, then Databas ently dropped daily — *	e retention policy, runs verified in
Usage and diagnostic 90 telemetry	days Scheduled retention	job
Account, workout Until history, plans, account measurements	you delete your
Heart-rate samples and wearable motion account	Until you delete your Del belong to	eted with the workout they
Deleted account Body-ge unlinked from you (Priv immediately and hours irreversibly; the on account itself permanently erased afte a 30-day grace period	ometry samples Applicatio acySweepScheduler), every , logged to privacy_event every run — verified	n sweep 6 s
De-identified movement measurements and to you reported counts, after you delete (retained_re	Kept, no longer linked Co and not linkable into a back identifier of any ki p_labels)	pied at the moment of unlinking table that holds no nd
Off-site backups **None	at present** —
Consent ledger Kept ind deliberately, as a regulatory record	efinitely, Append-only ta	ble

On deletion, precisely. Deletion happens in two steps, and the first one is immediate.

Step 1, at the moment you ask (irreversible). We do not merely delete the lookup table that connects your body-geometry samples to you — we rewrite the keys themselves. Every pseudonym and every session identifier on your pose frames, sensor streams, heart-rate samples and session metrics is replaced with a freshly generated value that exists nowhere else, and the old-to-new mapping is never written down anywhere. We do the same wherever your account identifier had leaked into diagnostics: usage telemetry, crash reports and the access-audit log. From that moment the samples are anonymous, and signing back in does not and cannot re-attach them to you.

Step 2, after the 30-day grace period. Your account, workout history, plans and everything that hangs off them are permanently deleted. Signing in within those 30 days keeps the account (step 1 still stands).

Until 2026-08-19 this paragraph continued: "Because backups rotate on a ~7-day cycle, deleted data leaves every copy we hold within about a week of the erasure executing." That is withdrawn rather than quietly deleted, because it was a representation about where your data ends up. No off-site backup has been taken since the Azure cutover, so today there is no backup copy for an erasure to have to reach. When backups resume, the rotation window has to be restated here — and it has to be a window that erasure actually propagates through.

What we keep, and why we say so here rather than in a footnote. On deletion we irreversibly de-identify your workout data and retain de-identified movement measurements and your reported counts to improve rep counting. Concretely: for each set, the number of reps you told us you actually did, how many our counter thought you did, the weight you entered, and the one-tap observation you gave us about the set. They are copied out at the moment of step 1, keyed only by the freshly generated identifier that replaced your session identifier, into a table that holds no account id, no pseudonym, no email, no device id and no foreign key to anything. Nothing you typed in free text is copied, because free text can name a person. The result is not "your data with the name removed" — the link was destroyed in step 1 and was never written down, so there is nothing left to reverse. It is a measurement of a movement that is no longer attached to anyone.

We keep it for one reason: those corrections are the only record of when our rep counter was wrong, and without them the counter cannot be made better for the people still using it. Verified: retained_rep_labels holds no identity column and no foreign key; AccountErasureCoverageTest fails if one is ever added, and AccountErasurePostgresIntegrationTest asserts both halves after a simulated deletion — the measurements are still there, and no join path from them reaches an account.

Verified: — the sweep enumerates every table holding an identity column, with a test (AccountErasureCoverageTest) that fails when a new one is added outside it; AccountErasurePostgresIntegrationTest performs a simulated deletion against a real database and then searches every column of every table for the erased identifiers. PrivacySweepScheduler runs step 2 and writes a privacy_events row on every sweep, including sweeps that find nothing, so a stopped job is distinguishable from an idle one.

What this replaces, stated plainly because a previous version of this document said otherwise: until 2026-08-19 deletion removed only the pseudonym record. A second link survived — each frame kept its session identifier and each session kept its owner — so 99.0% of stored body-geometry samples (477,547 of 482,151) remained one join away from the account, and no scheduled job ever deleted them. The wording here now describes the mechanism that exists.

[The FOLLOW-ON recorded here — erasure destroying the reps a deleted user had counted by hand to correct us — was closed on 2026-08-19: those corrections are now copied out de-identified before the rows go, and the paragraph above describes it. Recorded rather than deleted so the sequence stays on the record: the text was written first and the code made to match it, not the reverse.]

9. Your rights

In Settings → Privacy you can, today:

• Export your data as a JSON file.

• Delete your account. Your body-geometry samples are unlinked from you immediately and irreversibly; the account itself is permanently erased after 30 days. Signing back in within 30 days keeps the account — it does not re-attach the unlinked samples. We retain de-identified movement measurements and your reported counts to improve rep counting; they carry no identifier and cannot be linked back to you. §8 says exactly what is kept.

• Withdraw model-training consent at any time.

Your privacy event log. Every export, every deletion request, every consent change and every retention sweep is recorded in an immutable privacy_events log. An in-app viewer is planned; until then, request your log via privacy@getsvaya.com. (Carried forward from Version 2 §6.)

By writing to privacy@getsvaya.com you can also request access, correction, portability, restriction, objection, and a copy of your consent history. We do not discriminate against you for exercising any of these rights.

Depending on where you live you may also complain to a supervisory authority: your national data-protection authority in the EEA, the ICO in the UK, the Data Protection Board in India, or your state Attorney General in the United States.

10. Children

three options and their consequences are preserved in

of adults-only, with a family/kids mode held as a designed v2 built on on-device processing — see the 2026-03 kids-UX validation.)

Svaya is not directed to children, and we do not knowingly collect any personal data — including camera-derived body-geometry data — from anyone under 18. You must be 18 or older to create an account, and account creation requires an explicit age affirmation (recorded in the

18 has been collected, we will delete it and close the account. To report a suspected under-age account, contact privacy@getsvaya.com.

The statements below describe the mechanics as built, and are consistent with the decision above:

• Svaya is built for adults 18 and older only, with the parent/guardian path deliberately removed (founder decision, 2026-07-05).

• Age is collected as a self-reported number during onboarding and self-reported ages under 18 are refused. We require an 18+ affirmation before the app can be used. This is an affirmation, not a verified date-of-birth gate.

• Svaya is not directed to children and we do not knowingly collect data from anyone under 18. If you believe we hold data from someone under 18, email privacy@getsvaya.com and we will delete it.

11. India

India's Digital Personal Data Protection Act applies to us now — it has no turnover or user-count threshold, and we already process personal data of people in India, including at least one coach and their clients.

• Notice. This policy, presented in English before collection, is the notice.

• Consent. Free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and capable of being withdrawn as easily as it was given.

• Your rights as a data principal. Access, correction, completion, updating, erasure, grievance redressal, and nomination of another person to exercise your rights if you die or become incapacitated.

• Grievance officer. Grievance Officer, Vyoma Technologies Limited — support@getsvaya.com, 3296 Logsdon Loop, Delaware, Ohio 43015, USA. You may raise a grievance with the Grievance Officer before approaching the Data Protection Board. We aim to respond within one month of receiving it.

• Cross-border transfer. Your data is processed and stored in the United States on infrastructure operated by our hosting provider, and by the processors listed in §7.

12. Security

TLS in transit. Encrypted volumes at rest. Passwords stored only as salted hashes. Email and the 2FA secret encrypted at the field level. Signing keys and database credentials in managed secret storage, never in source control. Role-based access control on staff and coach access, with every access written to an audit table (1,375 entries to date).

No system is perfectly secure, and we do not claim otherwise.

13. Changes

We version this policy. When we change it materially we re-prompt you, and you accept the new version before continuing — which generates a new, independently verifiable ledger entry against the new text.

14. Contact

• Privacy, data rights, and deletion requests: privacy@getsvaya.com

• Everything else: hello@vyomatechnologies.com

• Postal: 3296 Logsdon Loop, Delaware, Ohio 43015, USA

Verified against source

Claim Source
Consent ledger is append-only, backe hash-chained, bound to the exact shown text	nd/src/main/resources/db/migrations/V67_
Ledger schema HAS request-metadata b columns (V96) but the server does §4 NOT populate them — the policy claimed capture until 2026-08-19, when the claim was withdrawn to match measured reality	ackend/src/main/resources/db/migrations/V96_;
30-day deletion grace period backend (pending_deletion_at). execute_pendi disarmed by V116 — it deleted which reaches none of the nine table reported success for a job it only p	/src/main/resources/db/migrations/V35_ ng_deletions from the same migration was the account row and trusted ON DELETE CASCADE, s that carry no foreign key to users, so it artly did
user_consents schema and its same mi improve_app opt-in intent	gration
Heart rate is stored as a raw backen timestamped series, with phase/set 2 recorded as contemporaneous app state and barred from grading a set	d/src/main/resources/db/migrations/V111_ (V90.106, 026-08-17)
Watch motion streaming was V90.105 ( unreachable until it was wired phone	2026-08-17) — startStreaming was called only from message handlers the had stopped sending; watch_accel non-null on 0 of 470,599 rows before the fix
Full-rate sensor_sessions upload V90 lane ships DISABLED	.105 — fullRateUploadEnabled = false, guarded at the enqueue
Prose is placeholder pending header counsel
Trainer video stored as bytes on, the host's own disk with a V82_, Postgres pointer row; no backup workflow for that store. Corrected 2026-09-03: this row said "a Fly volume" and cited backend/fly.toml. Since the 2026-08-19 Azure cutover the bytes live on the Azure VM at /data/app/trainer_videos_store. The host moved; the unbacked-up finding did not.	tools/azure/deploy_api.sh:125
media-egress grant exists
The erasure sweep genuinely com.fi executes advisory-locked so replic privacy_events on every run includin /api/v1/admin/privacy/erasure-sweep /api/v1/admin/privacy/erasure-sweep/ machines could not host an in-proces opened a proxy to the database we ha called performed a partial erasure. overwritten.*	tcoach.privacy.PrivacySweepScheduler — in-process, every 6 hours, as do not double-run, writing a retention_sweep row to g no-op runs; POST triggers it and GET status reports when it last ran. *This replaces., which was correct on Fly (auto-stopped s timer) and became wrong at the Azure cutover: it d migrated away from, and the SQL function it Both facts are recorded rather than quietly
Body-geometry upload is (rationale), unconditional; consent flags, (r not gates	:1189 / :1351 (flag read), :1353 untime log "storage is unconditional")
Model-training setting defaults off
Revocation de-flags rather than, :37 deletes	9-385
Telemetry consent is vestigial; — uploader has no consent check is	(no gate anywhere in file). This why §3.5 describes telemetry as always-on rather than offering a toggle
No pixels leave the device on the, D workout path	TO at :349-541
Pose inference is entirely iOS/FitCo on-device inference code in backend/	ach/PosePipeline/ — MediaPipe, ML Kit, Vision, ARKit estimators; no src/main/kotlin
HealthKit read/write type lists
Face redaction is not active in Fa production in-app copy	ceRedactor exists only in iOS/EquipTest/, referenced nowhere in the app target;
Group-participant consent is not (an	alytics event only);
ML Kit self-declares device-ID + iOS diagnostic collection	/Pods/MLKitCommon/Frameworks/MLKitCommon.framework/PrivacyInfo.xcprivacy
Live media bypasses our backend;
No payment processing exists today, off)	91-102; (COMMERCE_MODE defaults
Legal artifacts are generated from, this file, and drift fails the push	make lint-legal-drift

**Carried forward from the 2026-07-17 compliance audit

Training-eligibility filter missing on the backend export route (§1 item 9); LiveKit undisclosed and no DPA with Anthropic or LiveKit (§1 item 11); India DPDP compliance at zero (§1 item 10); DSAR export omits ~14 tables (§2 item 3); trainer video files survive account deletion (§2 item 2); health conditions, measurements and date of birth stored in plaintext (§2 item 11); ML-consent revocation not reaching the backend (§2 item 1).

Carried forward from the 2026-06-12 audit and the V82.8 implementation pass

Version 2 of this policy was the honesty revision produced from plus the V82.8 pass that made its promises real: legal pages served at /legal/*, the 30-day hard-deletion job scheduled, 90-day analytics retention enforced, the training-corpus training_eligible filter implemented, consent-revoke de-flagging rather than over-broad deletion, privacy_events logging on export / delete / consent, the export email decrypted, and the in-app consent UI made truthful. Known remaining items from that pass, still open: the in-app privacy-event viewer, a birth-date age gate, export table-coverage expansion, and the backup-identifier-stripping decision (audit #7 — whether to strip direct identifiers from the nightly dump).

Claims from the prior policies that this draft REMOVED as unsupported

1. "33 body keypoints." The stored data is 23 points in 95.8% of samples and 112–113 in the high-resolution mode. 33 appears nowhere in the distribution.

2. "A stick-figure skeleton… never pixels, never video" — the second half is true and is kept; the "stick figure" framing is dropped because it implies no facial or hand geometry, and both are stored.

3. "During a workout the watch streams heart rate, active energy, and raw accelerometer motion to your phone and on to our backend." Zero such values existed in production when that sentence was published, which is why it was removed. It has NOT been restored. §3.4 instead states the narrower and currently-true position: heart rate is stored as of V90.106; wrist and head motion can reach us only under an explicit opt-in that is off by default, wired as of V90.105.

4. "Head motion from AirPods never leaves the device." Removed rather than softened — see the correction blocks in §3.4. It is transmitted when the wrist-and-head motion setting is on.

↑ Back to contents

Sharing (DataSharingConsentView), and presented before the first tracked set

Why this document exists separately

Illinois' Biometric Information Privacy Act requires that, before collecting a biometric identifier, a private entity informs the subject in writing that it is being collected, states in writing the specific purpose and the length of time it will be kept, and obtains a written release. Texas' CUBI imposes a notice-and-consent duty and a destruction deadline. Washington's My Health My Data Act requires separate, specific consent for collecting consumer health data and a distinct authorisation before any sale.

Those are not satisfied by a paragraph inside a general Terms of Service. This is the separate written notice and release.

BIPA carries a private right of action and statutory damages per violation. That is the reason this document is drafted conservatively even though the question of whether our data is covered is genuinely arguable — see §7.

THE NOTICE

1. What we collect

When you run a tracked set, Svaya's camera measures where your body is, many times a second, and records the result as numbers.

Right now, each measurement records the position of 23 named points on your body. Five of them are on your head: your nose, both eyes, and both ears. The other eighteen are your neck, shoulders, elbows, wrists, hips, knees, ankles, heels, toes, and a central reference point. Each point is recorded with its horizontal and vertical position and a confidence score. Some capture modes also record a depth value and a three-dimensional position.

We also compute and store, from those points: 21 joint angles, the movement signal that drove your rep count, the phase of the movement, your rep count, your form score, and quality information about the camera.

A note about August 2026. For three days (1–3 August 2026) a higher-resolution capture mode was in use on some devices. It recorded 112–113 points instead of 23, adding your jaw, chin, eyeballs, and both eyelids of each eye, and a complete skeleton of both hands — thumb, index, middle, ring and little finger, three to four joints each. That mode is not currently in use. The measurements it produced are still stored, and will be permanently deleted 180 days after they were taken, in line with §3.

2. What we do NOT collect

No pictures. No video. No audio. The camera image is processed on your phone, in the moment, and thrown away frame by frame. It is never uploaded, and nothing we store can be turned back into a picture of you or of your room.

This is verifiable rather than promised: there is no image, video, or binary media column in the table that holds this data.

3. How long we keep it, and when we destroy it

Body-geometry measurements are permanently deleted 180 days after they are collected. This is enforced automatically by the database itself on a daily schedule, not by anyone remembering to run it.

If you delete your account, the record linking these measurements to you is destroyed immediately, and the measurements themselves age out within the same 180 days.

We publish this schedule here so that it is a stated, checkable commitment rather than an internal practice.

4. Why we collect it

• To count your repetitions and score your form.

• To measure your range of motion, tempo and consistency over time.

• To show you your history and progress.

• To let a coach review your movement — only if you have separately granted that coach access to this specific category of data. It is off by default and never included in any other permission.

• If, and only if, you switch it on: to train our own rep-counting and form-scoring models. See §5.

5. Model training is a separate choice, and it is off unless you turn it on

The Help Train Shared Models setting controls whether your measurements may be used to train and improve Svaya's own models. It is off by default.

Be clear about what this setting does and does not do:

It does whet control training	her your measurements are marked as usable for our models
It does not control — that because it is ho	whether measurements are collected and stored at all happens for every tracked set either way, w the app counts your reps

We spell this out because one of our own settings screens has described it loosely, in a way that could be read as an upload switch. It is not one. If you do not want body-geometry measurements stored, do not use tracked sets; log your workouts manually instead.

You can turn training off at any time. Future measurements stop being marked immediately. Measurements taken while it was on keep their marking — email privacy@getsvaya.com and we will clear them.

6. What we will never do with it

• We will never sell, lease, trade, or otherwise profit from your body-geometry data. Not to advertisers, not to data brokers, not to insurers, not to anyone, under any arrangement.

• We will never give it to another company to train their models.

• We will never use it to identify you to anyone, or to match you against any other database.

• We will never disclose it except: to you; to a coach you have specifically authorised; to a service provider hosting it under contract on our behalf; or where a court order or law compels us, in which case we will tell you unless legally forbidden.

7. Our position on whether this is "biometric" data

We think the honest answer is that it should be treated as biometric data, and we have written this notice on that basis.

The measurements include the geometry of your face, and — in the August 2026 captures — of your hands, which Illinois' statute names explicitly. We could argue that a 23-point joint map is too coarse to identify anyone and is not a "scan" in the statutory sense. That argument may well be correct. We have chosen not to rely on it, because the protections the statutes require are ones we are willing to give regardless: tell you first, in writing; say why and for how long; get your written consent; publish a destruction schedule; never sell it.

8. How we protect it

• Encrypted in transit and at rest.

• Stored under a pseudonym rather than under your name. Honestly: this is a single stable pseudonym, not a rotating one, and the measurements remain linkable to you through session identifiers. It reduces casual exposure; it is not anonymisation, and we do not call this data anonymous.

• Access by our staff and by coaches is role-restricted and written to an audit log.

9. Your rights

You may, at any time:

• withdraw this consent (below, or in Settings);

• turn off model training;

• export your data;

• delete your account, which destroys the link between you and these measurements immediately;

• ask us at privacy@getsvaya.com to clear the training marking from measurements already collected.

Withdrawing consent will stop tracked sets from working, because the measurement is the tracking. It does not affect manual logging, your history, or anything else in the app.

THE RELEASE

By tapping I agree, I confirm that:

• I have read the notice above and understand what Svaya measures, > why, how long it is kept, and when it is destroyed.

• I understand that these measurements include points on my face, and > that they may be treated as biometric data under the laws of > Illinois, Texas, Washington and elsewhere.

• I consent to and authorise Vyoma Technologies Limited, and the > service providers it names in its Privacy Policy, to collect, > store, use and destroy this data as described above.

• I understand this consent is voluntary, that I may withdraw it at > any time, and that withdrawing it stops camera-tracked workouts > but nothing else.

↑ Back to contents

PLEASE READ. THIS AFFECTS YOUR LEGAL RIGHTS.

1. Exercise is inherently risky

Physical exercise carries risks that no app can remove. They include muscle strains and tears, sprains, joint and back injuries, dislocations, fractures, overuse injuries, fainting, heat illness, dehydration, aggravation of an existing condition, cardiac events including heart attack, stroke, and — rarely — serious permanent injury or death.

These risks exist whether or not you use Svaya. Some of them are increased by exercising alone, without a qualified person present.

2. Risks specific to using Svaya

You should understand these before you accept:

• Nobody is supervising you. Svaya does not watch for your safety. If you are injured, lose consciousness, or need help, the app will not notice, will not summon anyone, and cannot assist. This is true even during a live coaching call: a coach can see you but cannot reach you.

• Svaya decides what exercises to give you, by software. Those decisions are automated estimates based on what you told it and what the camera measured. They may be unsuitable for your body, your injuries, your experience or your equipment.

• The rep count, the form score and the coaching cues can be wrong. They may miss repetitions, count ones you did not do, misread your form, or tell you your form is acceptable when it is not. An absent warning is not a confirmation that you are moving safely.

• Using a phone camera changes how you train. You may position yourself for the camera rather than for good mechanics, be distracted by the screen, trip over the phone or its stand, or continue a set you should have stopped in order to complete a count.

• Your environment is your responsibility. Floor surface, obstructions, ceiling height, equipment condition and stability, and other people or animals in the space are outside our knowledge and control.

3. You confirm you are fit to exercise

By accepting, you confirm that:

• you are voluntarily choosing to exercise, and are physically able to do so;

• you have had the opportunity to consult a physician, and have done so if you have any reason to;

• you have accurately told Svaya about your injuries and health conditions, and you will update that information if it changes;

• you are not exercising against medical advice.

4. You assume the risks

Knowing what is written above, you knowingly and voluntarily assume all risks of injury, loss or damage arising from your use of Svaya — including risks arising from your own physical condition, your environment, your equipment, and from Svaya's automated suggestions, feedback, rep counts and form scores being incomplete or wrong.

5. Release

To the fullest extent permitted by the law that applies to you, you release and discharge Vyoma Technologies Limited, and its officers, directors, employees, contractors and agents, from all claims, demands, damages and causes of action for injury, loss or damage arising out of or relating to your use of Svaya — including claims based on ordinary negligence — and you agree not to bring such a claim.

What this release does NOT cover, and cannot:

• gross negligence, recklessness, wilful or wanton misconduct, or fraud;

• any liability that the law where you live does not permit to be released, including — in many places — liability for death or personal injury caused by negligence;

• the acts or omissions of an independent coach, who is not covered by this release and is responsible for their own advice;

• your statutory consumer rights.

6. On behalf of others

You accept this on your own behalf and, to the extent the law allows, on behalf of your heirs, family, personal representatives and anyone claiming through you.

7. If part of this fails

If any part of this release is held unenforceable, the rest remains in force to the fullest extent the law allows, and the unenforceable part is limited rather than struck in its entirety where that is permitted.

8. Stop if something is wrong

Stop exercising immediately and seek medical attention if you experience chest pain or pressure, pain radiating into the arm or jaw, severe shortness of breath, dizziness, faintness, an irregular heartbeat, sudden severe pain, or any symptom that concerns you. Do not wait for the app to tell you. The app will not tell you.

The affirmation

↑ Back to contents

scope_or_value on the ledger row (currently "18_or_older")

Option A — Adults only, 18+ (the current build)

The affirmation: the user confirms they are 18 or older; under-18s are refused.

• Simplest compliance posture. No COPPA obligations, no parental-consent plumbing, no verifiable-parental-consent mechanism.

• Forecloses the kids/family market entirely.

• The honesty problem: children will use it anyway, on a parent's account. That is the classic COPPA "actual knowledge" trap — if the company ever markets to families, or has actual knowledge that a child is using an account, the 18+ clause is not a defence and the absence of any parental-consent machinery becomes the violation.

• The current gate is weaker than the clause. The date-of-birth check is client-side and can be skipped if the picker is left untouched, and telemetry is collected before the age check runs. An 18+ representation should be backed by a server-authoritative gate.

Option B — 13+ with verifiable parental consent below 18

The affirmation: users 18+ affirm for themselves; users 13–17 require a parent or guardian to accept on their behalf.

• Keeps the teen market. Common in fitness apps.

• Requires a real guardian-acceptance flow, guardian identity capture, and a guardian-facing copy of every document.

• Does not solve the under-13 case, which is where the validated use case actually sits.

Option C — Under-13 supported, full COPPA compliance

The affirmation: a child account exists only under a parent account, created by the parent.

• The only option that legitimately serves the validated market.

• Requires verifiable parental consent by an approved method — not a checkbox. Requires direct notice to the parent, parental access, review and deletion rights, strict data minimisation, no behavioural advertising, and a retention limit tied to the purpose.

• The hard part is not the paperwork. COPPA requires collecting no more personal information than is reasonably necessary. Svaya's core function is measuring the geometry of a body, including the face, and storing it on a server for 180 days. For a child, that is a substantially harder case to make, and it interacts directly with the biometric statutes in. It may require a materially different data posture for child accounts — for example on-device-only processing with no upload — which is a product and architecture decision, not a legal one.

The affirmation (Option A, as shipped)

I confirm I am 18 years of age or older. Svaya is available to adults only.

"age_attestation", scope_or_value = "18_or_older". This is a self-attestation, not a verified date-of-birth gate; onboarding additionally collects a self-reported age and refuses values under 18.

↑ Back to contents

BETA SOFTWARE ACKNOWLEDGMENT

1. This is pre-release software

Svaya is currently in beta. It is provided for testing and early use, not as a finished product.

2. Expect it to break

Beta software contains defects, incomplete features and untested paths. Svaya may behave unexpectedly, produce wrong results, crash, freeze, or be unavailable. Features may be added, changed or removed at any time, without notice, including features you have come to rely on.

3. Your data may be lost

Do not use Svaya as the only record of anything you care about. During the beta period your workouts, history, plans, measurements and other data may be lost, corrupted, reset or made inaccessible — including by our own mistakes while developing the product. Keep your own record of anything important.

4. Accuracy is not warranted during beta

Rep counts, form scores, plans and forecasts are under active development and are being changed frequently. Their accuracy during the beta is lower and less predictable than it will be at release. This does not reduce the risk of exercise, and it increases the importance of your own judgment — see the Medical Disclaimer, the Assumption of Risk & Release of Liability, and the AI & Automated-Feedback Disclaimer.

5. No warranty

Beta features are provided "as is", without warranty of any kind, to the fullest extent permitted by law.

6. We collect diagnostics

To find and fix problems, we record how the app is used and what errors occur. This is described in the Privacy Policy, is first-party only, and is not shared with advertisers or data brokers.

7. Being in the beta gives you no entitlement

Participating in the beta does not entitle you to the final product, to any particular feature, to a free or discounted subscription, or to continued access. We may end the beta, change who can use it, or discontinue Svaya entirely.

8. Please tell us what breaks

Reporting problems is genuinely useful and is the point of a beta. Email hello@vyomatechnologies.com. Feedback you send may be used freely by us, as set out in the Terms of Service.

The acknowledgment

↑ Back to contents

screen (MyTrainerView) Recorded as: the granted scope name in scope_or_value

THE SCREEN TEXT

What you are sharing with [coach name]

You choose what your coach can see. Each item below is a separate decision. You can change any of them at any time, and changes take effect immediately.

Nothing is shared until you turn it on.

What **What you	r coach sees if you turn it on**
Workout Which wor history exercises	kouts you completed, when, and the in them
Set detail Your	sets, reps, weights and rest times
Notes The notes	you write on a workout or set
Plan changes Pe workout plans	rmission for your coach to create and change your
Body Height, weig measurements	ht and the measurements you log
Health The injuri information	es and health conditions you have entered
Form review You the app detected	r form scores and the specific movement faults
Body-position A m replay during a s	oving figure showing exactly how your body moved et
Live Your rep cou monitoring	nt and form score, live, while you train
Live video Your c call	amera and microphone during a scheduled call

Read this before turning on body-position replay

Body-position replay is the most revealing thing on this list. It lets your coach watch a reconstruction of how your body actually moved — not a summary, a replay. It is off by default, and it is never included in any other permission here. Turning on "workout history" or "form review" does not turn this on.

Read this before turning on health information

Injuries and health conditions are sensitive. Share them with a coach only if you want that coach to plan around them, and only with a coach you trust.

What we do to protect you

• Every time your coach opens your data, we record it. You can ask us for that log at any time.

• Your coach cannot download or keep your data. Video access is granted only for a specific review, through short-lived links, and is withdrawn automatically when the review is finished.

• Coaches are told not to copy or record your data. We enforce this technically where we can. Honestly: we cannot make screen-recording impossible. Someone determined to capture what is on their screen can. The real protection is that we show a coach as little as your choices allow — which is why these switches are separate and default to off.

• Live calls are not recorded. The product has no recording capability at all.

Turning it off

Switch any item off, or end the coaching relationship entirely, at any time. Access stops immediately. It does not delete what your coach already saw or noted, and it does not affect their own records — ask your coach directly about those.

↑ Back to contents