Privacy Policy

Version 2.16 · Last updated 3 September 2026 · Supersedes v2.15 of 27 August 2026 · What changed in 2.16

1. Who We Are

This Privacy Policy describes how Oney Finansal Danışmanlık Turizm ve Dış Ticaret AŞ ("Omnisio", "we", "us") collects, uses, and shares your personal data when you use the Omnisio mobile application (iOS) and related services.

• Legal entity: Oney Finansal Danışmanlık Turizm ve Dış Ticaret AŞ
• Registered in: Turkiye
• Tax ID: 6430768526
• Trade Registry: 386006-5
• MERSİS number: 0643076852600001
• VERBIS Registration No: 74691528
• Data controller contact: privacy@omnisio.app
• DPO inquiries: dpo@omnisio.app

2. Important Disclaimer

Omnisio is a wellness coach — it will NEVER prescribe medication, recommend specific supplement dosages, or replace your physician's judgement. If a wellness reference range looks off, please discuss the result with your physician.

3. Data We Collect

3.1 Account & Profile

• Profile name (this is the name other members see in Community — there is no separate nickname)
• Email address
• Date of birth
• Biological sex (for wellness calculations)
• Country / locale
• Profile picture (optional, chosen by you from your photo library)
• Invite code (used for referrals and for friend requests)
• Sign-in provider (Apple ID, Google, or email/password)

3.2 Wellness & Wearable Data

• Heart rate (resting, continuous)
• Heart rate variability (HRV)
• Sleep duration and stages (light, deep, REM)
• Activity (steps, active minutes)
• Skin temperature (where supported by the wearable)
• Blood oxygen saturation (SpO2), where the wearable measures it
• Workouts and training sessions — the type, the duration, the effort, and the heart rate recorded during them
• Body composition measurements
• Self-reported logs: mood, hydration, and the days you marked as rest
• Menstrual cycle records, only if you turn tracking on — period start and end dates, flow, symptom entries, mood and energy
• Pregnancy and postpartum records, only if you turn tracking on — postpartum bleeding entries and the dates of a postpartum period. Turkish law counts these as both health data and data concerning sex life (KVKK Article 6/1). They were listed in the KVKK disclosure §2.3 and not here, and version 2.8 closes that gap

3.3 Community Data (optional)

• Friend requests and friendships
• Teams and challenges you create or join, including their names and descriptions
• Per-metric sharing choices, and the metric value you chose to publish
• Cheers you give on a friend's activity item
• Reports you file and members you block — see §8

3.4 Run Data (optional)

• Precise location, recorded only while a run is active — see §9
• Distance, pace, splits, laps, duration, calories
• Motion & fitness: cadence from the step counter, elevation from the barometer
• Heart rate during the run, when a band or ring is connected

3.5 Journal Entries (optional)

Which of a fixed list of daily behaviours applied to you, plus a free-text note — see §11.

3.6 Heart Signal Readings (optional)

Recorded with a compatible Omnisio Band and kept only on your phone — see §10.

3.7 Photos (optional)

Meal photos for the AI nutrition estimate, and a profile picture — see §12.

3.8 Device & Usage Data

• Device model, iOS version, app version
• IP address (at the time of API request, for security)
• Push notification token (when you enable notifications) — see §15 for who it passes through
• The identifiers of a wearable you have paired
• The raw payload of a device sync, kept for a short period so that a sync that went wrong can be explained — see §18

3.9 Purchase, Delivery and Billing Data

An Omnisio membership includes a device, and a device has to arrive at a real address. Ordering one directly from us therefore makes us process information the app on its own never needed — and, on a family plan, information about people other than you. The table below is the full contents of an order record.

None of the data in this section is used for advertising, none of it is used to build a marketing profile, and none of it is sold or rented to anyone.

3.10 Device Replacement Requests

If you ask us to replace your device, we store the request itself: which of your devices it concerns — including that unit's Bluetooth hardware address and product code — the reason you selected, any note you wrote, the membership tier the request was made on, and the status of the request. If we then replace the unit, a separate internal record links the device that left to the device that arrived, so your account carries a replacement history.

Both records are included in your data export, and both are deleted with your account.

3.11 Our Website

The Omnisio website sets no cookies at all. It stores two things in your browser's local storage and nothing else: the language you picked, so that the site opens in that language next time, and — only once you put something in the basket in the shop — what you put there, as a variant identifier and a quantity. Neither is sent to us on its own; the basket reaches us only as the contents of an order you place yourself. Both are listed by name on the cookie page. There is no analytics script, no advertising pixel and no social-network tracker on any page of this site, and nothing follows you from one site to another. That is why you are not being asked to accept anything.

One request is not ours, and until version 2.7 this section was wider than the truth. The store, checkout, order, home and Omnisio Team pages load their typefaces from a third-party font host. When your browser fetches a font file from another company's server, that company sees your IP address and which browser you are using. It sets no cookie, it is not tracking, and it never sees anything you type — but it is a third party receiving a request, and the sentence above used to deny that outright. The provider is listed in §15. This page and the other legal pages do not load it at all.

3.12 Morning Calibration — what your phone measures, and what reaches us

This section describes something that now runs. Every version of it up to 2.15 described a feature that was designed and switched off, and said that nothing in it was being collected. That is no longer the honest description, so the whole section is rewritten in the present tense. Morning Calibration is an optional measurement inside Omnisio Labs, on Horizon memberships, on iPhone only — it runs on Apple’s on-device Vision framework, so there is no Android version and nothing to switch on elsewhere.

The photograph never reaches us, and that is the design rather than a promise about our conduct. Your phone takes three frames of your own face on the same morning and measures them where they are taken. Each image is released as soon as the numbers exist: it is not written to storage, not uploaded and not kept. The interface that receives a morning has no field a photograph could arrive in — anything not on its list is rejected rather than quietly ignored — and no landmark, no facial template and no measure of colour is accepted either. This is a different arrangement from the meal photo in §12.1, which does leave your phone and is described there.

Four measurements cross the network, and every previous version of this section called all four of them ratios. Three of them are: how open your eyelids are, expressed in widths of your own iris; the area under your eye, divided by the square of your face’s width; and how much your left and right sides differ, divided by that same width. The fourth is not a ratio. It is an angle — the tilt of your mouth corners away from level, recorded in radians. The distinction is worth a sentence because “dimensionless ratio” was carrying reassurance in the old wording, and one of the four was never one. None of the four is a length, none is a colour, and four numbers of this kind cannot be turned back into a face.

A morning is more than those four numbers, and no previous version of this section said so. Stored beside them are the date of that morning in your own timezone and the instant of the capture, with the timezone offset used to work the two out; how good the phone judged the frames to be; how many captures the session managed; whether it declined to produce a reading and for what reason; and the model of your iPhone, its iOS version, the version of the app and the version of the consent you gave. There is one further column — the minutes between waking and the capture — and it is empty for every member. The only wake time the app could read means two different things depending on how it was synced, so nothing is written there rather than a figure that would be an observation on one path and an invention on the other. If it is ever filled in, this section is rewritten in that release.

A morning that refuses is not a morning we store quietly. When the frames are not good enough, nothing is sent at all — not an empty record, not a placeholder. No request leaves your phone, and there is nothing on our side to show that a morning was attempted. When the three captures do produce numbers but disagree with one another, those numbers are exactly the ones we have just decided not to trust, so they stay on the phone and what reaches us is the record of an attempt with no measurements in it. That record exists for one reason: so that we do not ask you to do the same morning again.

Nothing is told back to you about your face. There is no score, no percentage, no grade, no trend, no streak and no comparison with anybody else. The only output the design permits is whether the morning agrees with something your own physiology has already indicated — and today it produces none of those either: the feature is at its first stage and the answer it returns is “not available”. If it reaches the thresholds we published for it we will say so, and if it never reaches them we will say that instead.

We keep a morning for 24 months, or until you erase it, whichever comes first. The expiry is written onto the row once, when it is first created, and it is a real deletion date that our database acts on by itself. Re-doing the same morning updates the measurements and does not restart the clock. Twenty-four months is far longer than anything the product actually reads — the ageing model looks back about six months and the personal baseline uses sixty mornings — and that gap is deliberate: this is a ceiling, not a plan.

You can erase every morning at any time, from Privacy & Trust, at any membership level. The erasure is behind neither the Horizon requirement nor the feature switch, and that asymmetry is the design: a member whose Horizon has lapsed, or who has moved to a phone where the measurement cannot run, is precisely the person who must still be able to delete what was measured. When you ask, we delete and then read back to confirm that nothing of yours remains, and only then tell you it is done. If anything is still there you are told that nothing was deleted, rather than being handed a partial success. Deleting your account removes these rows with everything else (§17).

These rows are in your data export, and that is the one route by which they leave our own servers. An export is assembled into an archive and held with our file-storage provider until you download it, which is a transfer outside Türkiye and the EU — the same transfer §16 describes for every other part of an export. Nothing here is sent to an AI provider. Morning Calibration is not one of the six features in §13.1, and no facial measurement appears in any of those payloads.

It is not identification, and it is not a medical measurement. There is no facial template, no descriptor and no identity vector anywhere in the design, so we cannot recognise you from a morning and cannot match one member’s morning to another’s. It diagnoses nothing and screens for nothing, and it is not a medical device (§2). We do not treat these four numbers as biometric data, because nothing in the design can single you out from them: there is no template to match against and no matching step to run. That is our own position on how we process them, and we are not going to dress it up as a legal opinion — no lawyer has certified this section, and if that changes we will say so here. What we can put beyond doubt is the mechanism, and we have set it out above in full: what is measured, what leaves your phone, what does not, where it is stored, how long it is kept and how you erase it. Weigh it yourself rather than take our conclusion on trust.

One of the three conditions this section used to set is still outstanding, and we would rather write that down than let it pass. Version 2.15 said the switch would not be turned on until the measurement had passed its published thresholds, until this section described something live, and until our VERBIS registration (No. 74691528) carried the category. The second is now true. The first has been reframed rather than met: those thresholds govern whether we may ever tell you what a morning means, and we tell you nothing — they were never the right gate on the measuring itself. The third has not happened. Until the registration is updated, the feature is held closed in our server configuration, and no facial measurement is collected from anyone.

3.13 Blood Test Reports (optional)

You can bring us a blood test you had done yourself. Omnisio does not sell, order or run laboratory tests, and there is no partner laboratory (that correction is also published on the KVKK disclosure and the Data Deletion page). What we store is the report file you upload and the biomarker values read out of it, with their units, reference ranges, the report date and the laboratory it names.

These are clinical results about your body, so §4.1 applies to them in full. If you ask for the AI analysis, the report file itself is what leaves — see §13.1, which says exactly what that means. You can delete a report, with its values, without deleting your account, and both go with the account.

This section is new in version 2.8. The words "blood test" appeared once in the previous version of this page, inside an unrelated list of things Community never shows. A category of data this sensitive had no business being described only by omission.

3.14 Nutrition and Meal Log (optional)

Meals you log build up a nutrition record on our servers: what you logged, the portion, the estimated energy and macronutrients, any correction you made to an estimate, and the daily totals we roll up from them. §12.1 describes the photo and says we do not keep it; that was never a statement about the log the photo produced, and this section is here so the two are not confused.

3.15 Files You Import From Another Service (optional)

You can bring your history over from another wearable or app — a Whoop, Oura, Garmin or Apple Health export file. What you hand us is a file you obtained from that company, and what we keep is what we can read out of it: nights of sleep, days of activity, heart-rate history, and any daily answers it carried, each stored on the day it actually happened rather than the day you imported it. Imported records are yours in exactly the way the rest of your record is: they are in your export and they are deleted with your account. The KVKK disclosure §5.1 has listed this collection method since August 2026 and this page had not.

4. How We Use Your Data

4.1 Wellness data is treated as health data

Heart rate, heart rate variability, sleep, skin temperature, oxygen saturation, heart signal readings, workouts, body composition, the biomarker values off a blood test you upload, menstrual cycle, pregnancy and postpartum records, and the scores we calculate from all of them permit conclusions about your body. We therefore treat every one of them as special-category data under Article 6 of the KVKK and Article 9 of the GDPR — the strictest available reading — instead of arguing that a wellness score is somehow less than health data.

That has a consequence, and it is not cosmetic: for this data, the contract is not enough on its own. Explicit consent is what allows us to process it.

What the product records today, exactly — and this had to be split in three, because a single line describing it was wrong.

• The Deep Health Report. A versioned, append-only record on our servers: every acceptance and every withdrawal is stored as its own row, with the version of the wording you agreed to and the moment you acted. Nothing is overwritten, so the history stands as an audit trail. That consent is also checked on our side: without it the report is refused there, not merely hidden in the app. You withdraw in More → Privacy & Trust → AI Personalization.
• The other five AI features. Consent is asked for — the same screen, before the first use — and it is what the app checks before it sends anything. But the record of your answer lives on your phone and not on our servers, and our servers do not today refuse a request that arrives without it. Until version 2.8 the line above ran the two together as "AI features and the Deep Health Report", which claimed a server-side audit trail for consents that had none. §13.4 says what is built to close that, and what has to happen before it is switched on.
• Community metric sharing. Given metric by metric, off by default, withdrawn the same way (§7.2).

Sharing a wellness metric with Community is a second, separate consent. Publishing your recovery, readiness, strain, steps, sleep score or streak to a leaderboard makes health data visible to other people, which the consent above never covers. You give it metric by metric, it is off by default, and you take it back the same way (§7.2).

5. Apple Health (HealthKit) Integration

Omnisio can read health data from Apple Health if you grant permission in iOS Settings. We read:

• Heart rate, HRV, resting heart rate
• Active energy burned, steps, exercise minutes
• Sleep analysis (sleep stages where available)
• Body temperature, oxygen saturation (where available)

Apple Health data is processed on-device and sent to our servers only if you have an active Omnisio session and have not disabled cloud sync.

6. Wearable Device

Omnisio pairs with a consumer-grade wellness wearable via Bluetooth Low Energy. It is NOT a medical device and holds no FDA, CE-MDR or TITCK medical clearance.

We state no conformity marking and no certificate reference for the device on this page. Version 2.4 of this page stated that the wearable was CE-marked; that is a regulatory claim about a certificate we have not seen, so it has been removed rather than repeated. Nothing on this page should be read as a regulatory approval of any kind; the device's contractual description is in the Terms of Service §3.3.

Wearable data is read on-device, then uploaded to our servers when the app is open and you are signed in.

7. Community — What Other People Can See

Omnisio Community lets you add friends, create or join a team, run a challenge, appear on a leaderboard, and cheer a friend on. It is optional. If you never open Community, nothing in this section applies to you.

7.1 Your profile in Community

Two things about you are visible to other Omnisio members:

• Your profile name — the name on your Omnisio profile. Community has no separate nickname field.
• Your profile picture, if you set one.

Any signed-in Omnisio member can find you by searching your profile name or your invite code. Your email address, date of birth and phone number are never shown to other members and are never returned by member search. Someone you have blocked cannot find you at all.

7.2 Wellness metrics: nothing is shared by default

Exactly six wellness metrics can be shared with Community: recovery, readiness, strain, steps, sleep score and streak. Every one of them is OFF by default. There is no "share everything" switch, and no metric is ever enabled for you.

You opt in metric by metric in Community → What you share, or in More → Privacy & Trust → Community Sharing. When you turn a metric on and save, Omnisio publishes the value that metric holds at that moment. That published number then stays as it is until you open the sheet and save again — it is a snapshot you chose to publish, not a live feed from your body.

Turning a metric off deletes the published value, not just its visibility. Once it is off, there is no stored number left for anyone to see.

7.3 Who can see a metric you shared

• Friend leaderboards — you and the friends whose requests you accepted.
• Team leaderboards — the members of a team you belong to.
• Challenge standings — the participants of a challenge you joined.
• Activity feed — your accepted friends only. It shows that you turned a metric on (with the value you published), that you joined a team, or that you joined a challenge. Friends can "cheer" one of those items, which records who cheered what.

A member who has not opted into a metric simply does not appear in that ranking. We never estimate, average or fill in a missing value.

7.4 Teams and challenges

Creating a team or a challenge stores its name and optional description, who created it, who joined, and when. Names and descriptions are visible to everyone in that team or challenge. A team also has a join code: anyone holding it can join, so treat it as an invitation rather than a secret.

7.5 There is no chat

Community has no messaging, no direct messages, no comments and no photo posting. The only free text you can publish is your profile name and the name and description of a team or challenge you create. What is acceptable in those fields is covered by our Community Guidelines.

7.6 Leaving

You can remove a friend, leave a team, leave a challenge, or switch every metric off at any time. Deleting your Omnisio account removes your friendships, team memberships, the teams and challenges you created, and your metric shares. Blocks you placed are deleted with the account too. Reports are handled differently — see §8.3.

8. Safety: Reports, Blocks and Moderation Records

Community has a report button and a block button. Using either one creates a record that identifies the people involved. We are saying so plainly because it is a real consequence of tapping those buttons.

8.1 When you report someone or something

We store:

• Your user identifier, as the reporter
• The user identifier of the person the report is about — which we derive ourselves from the reported content, rather than accepting whoever the reporter names
• What was reported (a member, a team, a challenge or an activity item) and its identifier
• The reason you picked: offensive name, harassment or bullying, hate speech, spam, impersonation, inappropriate content, or something else
• Any detail you type, up to 500 characters
• The time it was submitted and its current status
• Once handled: which staff account resolved it, when, what action was taken, and an internal note

Reports are read by people. Authorised Omnisio staff review them through an admin-only moderation queue and act on objectionable content and abusive users within 24 hours. We never tell a reported member who reported them.

8.2 When you block someone

We store your user identifier, theirs, and the time. A block hides the two of you from each other in member search, leaderboards, teams and the activity feed, and removes any friendship between you. We never notify the blocked person. You can review and undo your blocks in Community → Safety → Blocked people.

8.3 How long we keep them, and why

We keep them as a safety and audit trail: to recognise repeat behaviour, to stop a permanently removed member from simply returning, to re-examine a decision when someone appeals it, and to answer a regulator or a court if we are required to. Our legal basis is our legitimate interest in the safety of our members, and compliance with a legal obligation where one applies.

If you believe a moderation record about you should be erased, write to privacy@omnisio.app. We will weigh your request against those interests and give you an answer.

Content removed during moderation — an offensive team name, a challenge title, a profile name — is deleted or replaced with a neutral placeholder. Suspending someone's access to Community never touches their wellness data, their export, or their right to delete their account.

9. Runs: Precise Location and Motion Data

9.1 When location is used

Omnisio collects precise location only while a run is active. Starting a run turns it on; finishing or discarding the run turns it off. There is no location collection when you are not running, and Omnisio never asks for "Always" location access — the only permission we request is "While Using the App".

9.2 What is recorded, and where it goes

During a run we record a series of points, each holding latitude, longitude, GPS accuracy in metres, barometric relative altitude where available, speed where the device reports it, and a timestamp. From those we calculate your route, distance, pace, splits, laps, and elevation gain and loss.

The finished run, route included, is saved on your phone and uploaded to Omnisio's own servers so your run history follows you across devices. Route points are not sent to any AI service, any advertiser or any other third party, and are never visible to other Omnisio members. Indoor and treadmill runs carry no route at all — our server rejects one if it is ever sent.

You can delete a single run, together with its route, from your run history at any time.

9.3 Motion & Fitness

While a run is active, Omnisio also reads motion data with your permission: the step counter, to show your cadence in steps per minute, and on iPhone the barometer, to measure elevation gain and loss. It is used for nothing else and only during a run. If you decline the Motion & Fitness permission, the run still records — it simply shows no cadence and no elevation, rather than an invented number.

10. Heart Signal Readings Stay on Your Device

With a compatible Omnisio Band you can record a single-lead heart signal reading.

Each saved reading holds the waveform, the average heart rate and HRV the band calculated, the duration and sample rate, any situation tags you picked (such as "rested" or "after exercise"), and any note you wrote. Your phone keeps your 30 most recent readings and drops older ones automatically.

A reading leaves your device only when you export or share it — for example by sending the exported strip to yourself or to a clinician. From that point it lives wherever you sent it, and this Privacy Policy no longer governs that copy. The export deliberately carries no name and no date of birth: it identifies the recording, not the person.

Because they never reach our servers, heart signal readings are not part of your data export, and deleting your Omnisio account does not delete them. To remove them, delete them in the app or remove the app from your phone.

11. Journal

The Journal lets you record, for a given day, which of a fixed list of behaviours applied to you, and add a free-text note. The list is: caffeine, alcohol, late meal, screen time in bed, meditation, reading in bed, sharing a bed, feeling unwell, being injured, and taking medication. Some of these carry a small detail you choose — the number of servings, or the time of your last coffee.

Journal entries are stored on Omnisio's servers, one entry per day, so they follow you across devices and can be lined up against your sleep and recovery trends. They are private to you: journal entries are never shown to other Omnisio members, never shared with advertisers, and are not sent to any AI service unless you separately consent to an AI feature that uses them.

The note is free text. Please do not put another person's private information in it. Your choice of which behaviours to track is a setting kept only on your phone.

12. Camera and Photo Library

12.1 Meal photos

The Food Scanner asks for your camera, or for your photo library if you would rather pick an existing photo. Omnisio only ever receives the single photo you take or select — never your photo library as a whole.

The photo is sent for an AI nutrition estimate, and that transmission requires your AI consent (see §13). If you have not consented, the photo does not leave your phone; the app asks you first and the analysis does not run.

We do not keep the photo. Once the estimate comes back, what we store with the analysis is the estimated foods and nutrition plus a one-way reference hash of the image — enough to recognise a repeat of the same photo, not enough to reconstruct it. The photo itself is not retained on Omnisio's servers.

12.2 Profile picture

Setting a profile picture opens your photo library so you can pick one image. The picture is uploaded to Omnisio's own servers and is shown to other members in Community. It is served over a direct link that is not itself access-controlled, so anyone holding that link can open the image. You can replace it at any time. Profile pictures are not sent to any AI service.

13. AI Service Data Sharing

13.1 The six features that send data, and what each one sends

Six features in Omnisio send data out of our servers for AI processing. Every one is optional and every one asks first. Until version 2.8 this section began "When you opt-in to AI-powered features (Today's Insight, Food Scanner), Omnisio sends the following data" — a closed list naming two of the six. The four it left out include the two that carry the most: a clinical laboratory report, and whatever you type into a chat about your own health. Here are all six.

Every one of these requests also carries your locale (for example "tr-TR") and a request identifier. None is made from your phone: the request leaves our servers, so the provider sees Omnisio's address rather than yours.

13.2 What We Do NOT Send

• Your email address or phone number
• Your name, on five of the six AI paths — the blood test path is the exception, and both of the ways it is an exception are named in §13.1
• Your precise location, your run routes, and your IP address
• Your heart signal readings — those never leave your phone at all (§10)
• Your profile picture (§12.2), and any photo other than the single meal photo you chose
• Government identifiers, including a national identity number a payment rail asked you for (§3.9)
• Other members' data
• Anything at all, on any of the six paths, before you have been asked and have accepted

13.3 Who receives it, and how far the chain goes

Omnisio holds credentials with one AI company and calls no other. We identify it here as a third-party AI processing provider rather than by trade name, which Article 13(1)(e) of the GDPR permits — and the identity is yours for the asking: write to privacy@omnisio.app and we will tell you.

The request does not stop with that company, and describing the chain honestly matters more than describing it tidily. The endpoint we call is a routing endpoint, and it takes the name of a model as a parameter — which means our provider hands the request onward to whoever operates that model instead of running it itself. So there are at least two companies in the chain: the one we contract with, and the one that runs the model. We can state that much because it is visible in the call our own code makes. What we will not do is name a third company as a fact when what we actually hold is the name of an endpoint. Until version 2.8 this section described a "model-routing infrastructure provider" as a separate sub-processor and gave its retention practices; that put a second company's name-shaped hole in the document and then described its behaviour, which is more than we know.

• Retention by the AI processing provider: its processing addendum provides that it holds what we send until our agreement with it ends, rather than for the life of a single request — earlier versions of this bullet said "standard processing of the request", which read shorter than the document does (§13.5). We use a paid tier whose published terms exclude the use of requests for model training; that exclusion sits in the tier's terms and not in the addendum, and §13.5 sets out why the difference matters.
• Retention by Omnisio: an AI response is cached for up to 24 hours so that the same question is not paid for twice. A cached Today's Insight is served without anything being sent at all.
• What Omnisio keeps of the result: the analysis rather than the input — the nutrition estimate rather than the meal photo (§12.1), the report rather than the extract it was written from. A Concierge conversation is stored on our servers as your chat history and is deleted with your account.

13.4 Your consent, and where the record of it lives

Before an AI feature runs for the first time, Omnisio shows the AI Consent Screen describing what is above. You may:

• Accept — AI features are enabled
• Decline — AI features stay off, and the rest of the app works without them
• Withdraw — at any time in More → Privacy & Trust → AI Personalization. Further requests stop. One already answered cannot be recalled, but nothing more is sent.

13.5 Equal Protection

Omnisio is a paying customer of the AI provider it calls, and the provider's data processing addendum applies to that account and has now been read. Two things about it come before anything else, because they set what the rest of this section is worth. It is the provider's standard addendum — published openly and incorporated into the terms we accepted, not negotiated for us and not signed page by page. Holding a document and having bargained over it are different claims, and only the first one is ours. And it is a document that can move: it carries its own "last updated" date, and the version read for this release is the one dated 31 July 2026. What follows is what that version says, and it stops where the document stops.

What it covers. Each of the following is in the document, and each is one of the things Article 28(3) of the GDPR requires a processor arrangement to settle.

• Purpose. The provider processes what we send only on our documented instructions — which the document defines as the addendum itself, the terms behind it, and what our own configuration of the service asks for — and otherwise only where a law requires it, in which case it must tell us before it does so unless the law forbids telling us.
• Confidentiality. The people it allows near the data are under confidentiality obligations.
• Security. A written security programme, described with specifics rather than adjectives: access on a need-to-know basis and withdrawn once it is no longer needed, unique credentials per user, encryption of the data in transit across public networks and at rest on its systems, vulnerability scanning with remediation ordered by severity, data-loss-prevention tooling, network segmentation, physical access controls. It may change those measures only in ways that do not lower the level of protection.
• Breach notice. It notifies us without undue delay after becoming aware of a security incident, takes reasonable steps to limit it, and helps us meet our own notification duties. That is worth reading slowly: the duty runs to Omnisio, not to you. Telling you, and telling a regulator, stays our job (§20).
• Deletion. At our choice it deletes what we sent, and existing copies of it, after the agreement ends — keeping only what a law obliges it to keep, and only for as long as that law says. A certificate of deletion is ours on written request.
• Audit. It commissions SOC 2 Type II and ISO 27001 audits, or equivalents, and gives us summaries of the current reports when we ask. Where those summaries are not enough for us to judge its compliance, we may audit on site on 30 days' notice, ourselves or through an independent auditor.
• Sub-processors. It may use them, and we have agreed in advance that it may. Against that it owes us 15 days' notice before a new one is engaged and we have 10 days to object; if an objection is not resolved in a further 10 days, either side may end the part of the service that cannot be provided without the objected-to company. It must bind each sub-processor to protections no weaker than its own, and it answers to us for what they do as it does for itself.
• Helping us answer you. Where our own use of the service does not let us handle something you ask for under §17, it assists; the same for data protection impact assessments. If a public authority demands the data, it tells us wherever the law lets it, so that we have the chance to object or seek protection.
• The transfer itself. The EU Standard Contractual Clauses — Module Two, controller to processor, with us as exporter and the provider as importer — are incorporated into the addendum and treated as executed, for transfers to countries with no adequacy decision. The UK addendum to those clauses covers data under the UK GDPR, and a Swiss variant covers Swiss data. Disputes under the clauses go to Irish law and the Irish courts.

What this settles for Turkiye: nothing. The Standard Contractual Clauses are the European mechanism, and the KVKK is not satisfied by them. Article 9/4 wants one of its own — binding corporate rules approved by the Board, the Board's own standard contract notified to it within five working days of signature, or an undertaking with the Board's permission — and this addendum is none of the three. The position written in §4.1 of the KVKK disclosure is untouched by it: we hold no record of such a contract for any processor, and that section says so in those words. As for Article 12, the controller's own duty to keep data secure, the security exhibit above is evidence we can point at for having chosen this processor rather than another. It is not a discharge of that duty, which stays ours.

What this section said before, and why the old sentence is not simply restored. Until version 2.8 it said: "We have reviewed their data processing agreements (DPAs) and are satisfied they meet GDPR Article 28 and KVKK Article 12 requirements." That was withdrawn in 2.8 as an unverified compliance claim — being a company's customer is not the same as holding a processing agreement with it, and nobody could point at one. From 2.8 to 2.13 this section said the customer relationship was the whole of what we could state. The document has now been obtained and read, and this version writes down what is in it. The withdrawn sentence does not come back. It claimed satisfaction on two limbs, and the second — KVKK Article 12 — is not something a European processor addendum delivers, as the paragraph above sets out. What replaces it is a description rather than a verdict: whether an arrangement satisfies Article 28 for a particular kind of processing is a judgement, and a page that has removed other people's compliance verdicts (§16.1, §20) should not award itself a new one.

14. Buying a Membership: Payment, Delivery and Your Device

This section covers the data side of a purchase. What you get, what it costs, and what the cancellation and withdrawal rules are belong to the Terms of Service. If the two ever appear to disagree, the Terms describe the deal and this page describes the data.

14.1 Two ways to pay, two different data paths

Where you buy decides who handles your payment, and it changes what we ever see.

• Bought inside the iOS app. Apple sells and processes it. We never see a card, a billing address or your Apple account email. We use RevenueCat as our receipt aggregator; it receives your anonymous Apple User ID (a long opaque string, not your email), Apple's receipt verification token, the subscription product identifier and renewal status, and a country code for tax purposes. RevenueCat does not receive your name or your email address. See the RevenueCat privacy policy.
• Bought outside the app. A payment provider processes the card, and we process the order. The full contents of an order record are itemised in §3.9: your name, delivery address, phone number, email address, invoice details, line items, payment references — and, on a family plan, the email addresses of the people you added. The card itself still goes to the provider and never to us.

14.2 Delivery

To ship a device we hand the carrier what a carrier needs and nothing beyond it: the recipient's name, the delivery address, the phone number, and a description of the contents. The carrier does not receive your health data, your Omnisio account data or your order value.

The carrier decides for itself how long it keeps delivery data and under what rules; we do not set that. No tracking number and no delivery status come back to us today: no carrier system is connected to ours, so that field on an order record is empty and stays that way, and a parcel is chased up by a person. On the day a carrier integration is live, both come back and are stored on the order (§3.9). If your device is shipped to a country other than the one our operations are in, your delivery details reach a carrier in that country — that is a cross-border transfer, and §16 applies to it.

14.3 Replacing your device

While your membership is active, a device that fails gets replaced. Doing that means processing the replacement request (§3.10), the serial numbers of the unit that leaves and the unit that arrives, and a delivery address for the new one. Where a manufacturing fault is involved we may pass the serial number and a description of the fault to the manufacturer. We do not pass your health data with it.

14.4 If you withdraw, cancel, return or are refunded

Exercising a right of withdrawal or cancellation, returning a device, or being refunded is itself something we have to record and be able to prove: what you asked for, when you asked, what we did, and when the money went back.

We now hold that record. A withdrawal, cancellation, return or refund on an order placed directly with us is written onto the order itself, and it follows the retention in §18 — which today means it goes when the order goes, and the order goes when you delete your account. A purchase made in the App Store is unchanged: a refund there is Apple's record rather than ours. Version 2.6 said we held no such record and promised to say so here on the day that changed. This is that day.

14.5 Referrals

If you invite someone with your invite code, we store the pairing between the two accounts and the credit it produced, so that both sides receive what they are owed and the same account cannot be credited twice. Referral records appear in your data export and are deleted with your account. An invite code tells the person you invited nothing about you beyond what Community already shows (§7.1).

A family plan invitation is a different thing, and we do not want the two confused. There we do tell the person something about you: your full name and the date you entered their address. We are required to — someone who never gave us their data has the right to be told where it came from (GDPR Article 14(2)(f); KVKK Article 10). That is the whole of what they learn about you. Not your email address, not what you paid, not anything from your account or from Community. See §14.6.

14.6 Family plans: when you enter someone else's email address

A family plan is one payment that buys between 3 and 10 memberships. You enter the email addresses of the people the other places are for. That is the first time Omnisio has ever asked a customer for another person's personal data, and it deserves saying plainly: from the moment you type an address, that person is our data subject too — and we did not get their data from them. We got it from you.

What we send them. Each address receives one email. It says who bought the membership — your full name — the date you entered their address, which plan it is, and how to claim the place. In the same email, not behind a link, it tells them what we hold about them (their email address and nothing else: no name, no phone number, no address, no health data), why we hold it, how long, who else sees it, what their rights are and where to complain. It also carries a one-click link that removes their address: no sign-in, no form. That email is transactional. It carries no offer, no other product and no marketing sentence.

The legal basis is legitimate interest, not consent. We rely on GDPR Article 6(1)(f) and KVKK Article 5/2-f: our interest is getting the membership you paid for to the person you paid it for. It is deliberately not consent, because consent has to come from the person whose data it is and nobody can give it on someone else's behalf. When you enter an address we ask you to confirm that you know the person and are entering it with their awareness. That confirmation is a promise you make to us. It is not their consent, and we will not describe it as one.

What you see, and what you never see. As the person who paid, you see the status of each place: invited, claimed, not claimed, or moved to another address. You do not see the member's name, you do not see their delivery address, and you never see any of their wellness data — not recovery, not sleep, not runs, not journal, not a single metric. A family plan is a way of paying for someone's membership. It is not a way of watching them.

An address that is never claimed. If nobody claims a place, we delete that email address 90 days after the last invitation we sent to it. During those 90 days you can change it to a different address. The place itself stays yours for the whole period you paid for: losing the address does not cost you the place. After the 90 days the address is gone from the live system, and what remains is the order record, which keeps what you bought for the statutory period in §18.

Moving a place to someone else. A place that has not been claimed can be moved to a different address at any time. A place that has been claimed and is an active membership cannot be moved during the term. You can cancel it, and the move then takes effect at the end of the period you have already paid for; the person using it keeps their membership until that date. We are not going to take a working membership away from someone in the middle of a term because the person who paid changed their mind.

If the member deletes their account. Deleting an Omnisio account removes that person's own data — and their email address comes out of your order with it. Both copies of it: the place itself, and the list of addresses your order was frozen with at checkout. What you are left with is a place carrying no address and no reason for why it emptied. If that person had accepted the place, it reads as ended and you can name the address it goes to next, taking effect at the end of the period you have already paid for. If they never accepted it, it is simply an empty place and you can give it to somebody else straight away. Until this correction this paragraph said their address stayed on your order because it was part of a commercial record. It does not stay. §17 carried the same sentence as its fifth limit and has been corrected with it; a person who was invited and never signed up has their own section at §17.1.

If you delete your account, the memberships you paid for do not go with it. The order stays and the places on it stay. Everybody who accepted one keeps their membership, their own delivery address and their own data until the last day of the period you paid for. We took that money in full and in advance, for those people; your leaving is not a reason to take back from them what was already bought. What goes is you: your email address, your phone number, your name and your delivery address are erased from the order, your own place on it is emptied, and the order can no longer be opened — the reference and your address stop working together, so nothing that used to be your credential can be used to read the other members' addresses. Nothing renews afterwards, and nothing ever did: this service has no mechanism that renews a membership by itself, so a paid term simply runs out on its date. The members are told that date — one notice as soon as this happens, then again 30 days and again 7 days before the end, or only the notices still ahead of them if less time than that is left. Those emails give the end date and what they can do about it. They do not mention you. Closing your account is your own act, and it is not news we pass on to people who happen to have benefited from what you bought.

Age. Every place on a family plan sits under the same floor as every other membership: nobody under 16 (§19). Buying a place for someone does not change how old they are.

14.7 Ordering without an account

You can order from us without creating an Omnisio account. If you do, we hold what any order needs — your name, delivery address, phone number, email address and the order itself — with no account attached to it. Until version 2.7 this page had no concept of a buyer without an account. It should have had one before the first such order was possible, and this section is that correction.

How you open it again. A guest order is opened with the order reference plus the email address you used. We store a one-way hash of that address and compare it with what you type; together the two work like a password for that one order. Keep the reference to yourself for the same reason you would keep a password to yourself.

Deleting it: there are now two answers, and which one you get depends on whether anybody else is on the order. Account deletion used to reach nothing here, because a guest order carries no account. It now reaches one through the verified email address on your account: an order placed with that address is yours, and deleting your account deletes it — the order, its line items, its payment attempts and anything a provider sent back with it. One order is not deleted, and it is the one that is not only yours: a family plan you paid for. Between three and ten other people's memberships hang off that order, and ending them because you closed your account would take away something bought and paid for on their behalf. That order stays, emptied of you — your email address, your phone number, your name and your delivery address are erased from it, and it can no longer be opened with the reference (§14.6). A family checkout that never took money has nobody on it, and it is deleted like any other order. All of this is keyed on an address your account has verified: where there is none, none of it runs, and the way to have such an order dealt with is to write to privacy@omnisio.app with the order reference. What we can then do is bounded by the same retention as any other order (§18).

15. Other Third-Party Services

16. Data Storage & Transfers

16.1 Where your data is stored

Omnisio's application server runs on Railway and its database is a managed MongoDB Atlas cluster, under contracts that make them processors acting on our instructions and for no purpose of their own.

Until version 2.8 this section said we identify our providers "by category rather than by trade name" — and four paragraphs further down, §16.2 named a country, a cloud region and a city. One page cannot hold both sentences, and the contradiction was visible to anyone who read on. The rule we actually follow is narrower, and it is written here instead of implied: we name a recipient once we have verified it, and we describe one by category where naming it would state more than we know. That is why Apple, Google, RevenueCat, Railway and MongoDB Atlas are named on this page while our AI provider is not (§13.3) — a category is what Article 13(1)(e) of the GDPR permits, and the identity is yours for the asking: write to privacy@omnisio.app and we will tell you.

16.2 Transfers outside your country

Some recipients sit outside Turkiye and outside the European Union. Apple, Google and RevenueCat are established in the United States, as is our third-party AI processing provider. So is our transactional email provider, which means an address you enter for a family member leaves your country as soon as the invitation is sent; so is the push notification service every notification passes through before it reaches Apple; and so is the object storage provider that holds profile pictures and, for seven days, the archive a data export produces. Where a device is shipped abroad, the carrier that delivers it is in the destination country, and the payment provider that processes a card is normally in the country that card was issued in.

Transfers from the European Union rely on Standard Contractual Clauses, and on the EU-US Data Privacy Framework where the recipient is certified under it. Transfers from Turkiye rely on the mechanisms in Article 9 of the KVKK. Our managed database is recorded as running in Germany (AWS eu-central-1, Frankfurt) — read the sourcing note in §16.1 before relying on that sentence — and our application server runs outside Turkiye, so the service itself, not just a list of third-party recipients, involves a continuous transfer abroad. Which Article 9 mechanism that rests on, and what is still outstanding, is written out in §4.1 of the KVKK disclosure. Where a recipient above is described by category rather than named, the reason and the rule are in §16.1; the identity is yours for the asking at privacy@omnisio.app.

16.3 If you are in the Russian Federation

Your data is processed as this policy describes wherever you are, and every right in §17 is available to you in full.

What we can state as fact. Cards issued in the Russian Federation are not accepted for a direct purchase (§15), so no order, invoice or delivery record is created here from a Russian card. Our servers and our database are outside Russia. This page, the app and the family plan invitation are published in Russian.

What is unresolved, and we are not going to dress it up. Russian law requires an operator collecting personal data of Russian citizens to record, store and update it using a database located in Russia (Federal Law 152-FZ, Article 18(5)), and to notify the regulator before a cross-border transfer (Article 12). Whether that reaches a Turkish company with no Russian entity, which takes no Russian cards and reaches people in Russia only through a Russian-language app, is a question about how far a foreign law extends. It has not been answered for us. We have made no notification under Article 12.

What the family plan changed, and why it is written here. Until this version nothing on this page created a record about a person in Russia, so the open question stayed theoretical. It is no longer theoretical in one specific way: a customer anywhere can type the email address of a relative living in Russia into a family plan, and that address is then written into a database outside Russia. Refusing Russian cards does not close that door, because the person whose data it is is not the person paying.

Our position for now. We are not claiming compliance with Russian localisation law, and we are not claiming it does not apply. Either claim would be one we cannot back, and version 2.6 said the review was in progress at a time when nothing was being collected — a sentence that was honest then and would not be honest now. So we are stating the exposure instead, and treating the decision as open and pending. If you are in Russia and this matters to you, write to privacy@omnisio.app: we will tell you where the answer stands and, if you ask, remove your address rather than leave it somewhere neither of us can assess.

17. Your Rights (KVKK / GDPR / CCPA)

You have the right to:

• Access your data and receive a copy (in-app: More → Privacy & Trust → Your Data → Export My Data)
• Rectify inaccurate data
• Delete your account and data (More → Privacy & Trust → Your Data → Delete Account, or Profile & Settings → Data & Privacy → Delete Account — the same control, reachable two ways). Deletion is immediate and irreversible; what it removes and what survives it is itemised on our Data Deletion page
• Restrict processing
• Object to processing based on legitimate interests
• Portability — receive your data in machine-readable format
• Withdraw consent for AI features (More → Privacy & Trust → AI Personalization)
• Withdraw consent for any shared wellness metric, one metric at a time (Community → What you share)
• Lodge a complaint with KVKK (Turkiye), your EU supervisory authority, or your local data protection authority

Five limits worth knowing in advance. Moderation records — reports — survive account deletion for the safety and audit reasons set out in §8.3; ask us and we will weigh an erasure request against those interests. Heart signal readings never reach our servers, so they cannot appear in an export we produce and are not removed by deleting your account — they are removed by deleting them in the app or removing the app (§10).

The third limit now bites, and until this version it did not. The right to erasure does not override a legal obligation to retain (KVKK Article 7; GDPR Article 17(3)(b)), and Turkish tax and commercial law requires invoices and the order records behind them to be kept for a fixed number of years whatever you or we would prefer. Omnisio now creates those records. What it does not create yet is the document that starts the clock: Article 82 runs on commercial books and the documents behind them, and the document it needs here is an invoice — which we do not issue, because the accounting and e-invoicing integration is not connected (§18). So the honest answer today is the opposite of the one this paragraph used to give: deleting your account deletes the order attached to it, with its line items, its payment attempts and the provider's notifications. On the day invoicing is connected, an invoice and the order behind it stop being deletable, and this paragraph changes in that release and not before it. Versions 2.5 and 2.6 of this page said we held no order records at all; that was true when it was written and it is not true now.

What an order holds, so that you know what goes with it: who bought what, when, for how much, to which address, the line items and the payment references — and, on a family plan, the email addresses you entered for other people, the status of each place and the history of the invitations we sent. Version 2.6 said the commercial record "and nothing else"; that was written before family plans existed and it understated what an order contains. Wellness data, runs, journal, community graph, replacement history and the account itself go with it. One order is not reached by deleting your account, and it is the fourth limit below: a family plan you paid for, which carries other people's memberships. The fifth limit below used to be a second one — somebody else's order carrying your address — and it is no longer a limit at all. The periods are in §18.

The fourth limit, which has narrowed: an order you placed without an account. A guest order placed with the email address your account has verified is now deleted with your account, together with its line items, its payment attempts and any provider notification. Until this correction none of that was reached at all. What is still not deleted is a family plan you paid for: other people's memberships sit on that order and run to the end of the period you paid for, so the order survives with everything that identified you erased from it (§14.7). For an order placed under an address your account has not verified, write to privacy@omnisio.app with the reference; the period in §18 applies to it exactly as it does to any other order.

The fifth limit is gone: if someone bought you a place on a family plan. We would rather say that plainly than leave standing a sentence that made us look more careful than we were. Deleting your Omnisio account now also removes your email address from the order of the person who paid — from the place itself and from the list of addresses their order was frozen with. Nothing of yours is left inside their record. They are left with a place carrying no address, and they are told nothing about why (§14.6). Earlier versions of this page said that address stayed with their commercial record and that you had to write to us separately about it. You do not.

One precondition, because it decides whether either of those two paragraphs happens at all. Everything account deletion does by address rather than by account — the guest order, the family order, your place on somebody else's order — runs off the email address your account has verified, read at the moment of deletion. Where an account has no verified address, or we cannot read it, those steps do not run: the account and everything attached to it still go, and the deletion record we keep says the address-keyed part was skipped. We would rather leave that behind and tell you about it here than erase a stranger's invitation because an unproven address happened to match theirs. If that is your situation, write to privacy@omnisio.app.

Asking for your data makes a second copy of it, and you should know where that copy goes. An export is built into a single archive file and put in private object storage (§15). You are given a link to it, and the link and the archive both stop existing after 7 days; deleting your account before that deletes the archive with everything else. That file is the whole of what we hold about you in one place, so treat the link the way you would treat the file. No version of this page mentioned the archive before 2.8, which meant a member exercising the most protective right on this list was doing so without being told the shape of it.

Three records stay behind when you delete your account, on purpose, and none of them is about your health. They are listed with their periods in §18, and they have not been described here before:

• An erasure receipt. One row recording that the deletion happened and whether your Sign in with Apple grant was revoked with it. Deleting it alongside the account would destroy the only proof that we did what you asked.
• A credential audit trail. Sign-in and API-key events — what happened, which credential, what the outcome was. Never an address, never a token, never anything you measured. It is what makes credential abuse against other accounts visible, which is the narrow ground on which erasure law leaves such a record standing.
• The membership grant row, emptied rather than deleted. Where you held a membership bought on omnisio.app, your user id, your email address and its hash come off the row and the grant is marked revoked — but the row's key stays. Deleting it is what let a later routine reconciliation quietly rebuild that membership against your address and hand it to whoever registered it next. What is left describes a purchase and names nobody.

To exercise these rights: privacy@omnisio.app. We respond within 30 days (KVKK Article 13).

17.1 If you were invited to a family plan and never signed up

You may be reading this because an email arrived saying somebody bought you an Omnisio membership, and you have no account with us and do not want one. You have rights here, and they do not depend on becoming a customer.

What we hold about you: your email address and a one-way hash of it. Nothing else — no name, no phone number, no address, no health data of any kind. Where we got it: from the person who paid, who entered it at checkout; their name and the date are in the email you received. Why: to deliver the membership place bought for you, on the basis of legitimate interest (GDPR Article 6(1)(f); KVKK Article 5/2-f) — not consent, because you never gave any and nobody can give it for you. How long: 90 days after the last invitation, then deleted.

How to end it now. The invitation email carries a one-click removal link: no sign-in, no form. Following it deletes your address and records it so that the same address cannot be invited again. You can also write to dpo@omnisio.app. You have the right to object to this processing outright (GDPR Article 21; KVKK Article 11), and if you object we stop. We do not ask you to justify it and we do not ask the person who paid.

That one click reaches further than this page used to admit, and the correction is in your favour. Following the link deletes your address from all three places it is stored: the place that was being held for you, the invitation record behind it, and the list of addresses inside the order of the person who bought the plan. Nothing of yours is left in their record. Until this version this paragraph said the copy inside their order was the one thing we could not undo and that your objection did not reach into it. It does reach into it. That was the worst sentence on this page — telling you we could not do something for you that we in fact do — and it is why this paragraph now begins the other way round. What the buyer is left with is a place carrying no address, and no reason for it. What we keep is a one-way hash of your address on a suppression list, for the single purpose of never writing to it again. The link works while the place is unclaimed; once a place has been accepted it belongs to an account, and the route from there is account deletion (§17), which now takes the address out of the buyer's order as well.

18. Data Retention

An order is not one clock. Until this version this table treated an order as one item with one period. It is not. An order row holds a commercial record that Turkish law locks for ten years and, sitting next to it, the email address of somebody who may never become a customer. Those two cannot share a retention period, so the table below is by field rather than by row.

Why two different clocks. The KVKK and the GDPR say we may keep personal data only as long as its purpose requires. Turkish tax law says an invoice must be kept for five years; the Turkish Commercial Code says commercial books and the documents behind them must be kept for ten. When those rules point at the same document and disagree, the longer statutory period wins — and the data is then locked to that purpose alone. The ten years do not start on the day you order. Article 82/6 of the Turkish Commercial Code runs the period from the end of the calendar year in which the record was made, so an order placed in March 2026 is kept until the end of 2036, not until March 2036. An order record kept for ten years exists for accounting, audit and legal defence and for nothing else: not to profile you, not fed back into the app, and not a way of keeping your account alive after you deleted it. This is now in operation (§3.9).

19. Children and Young People

Omnisio is not for anyone under 16. We do not knowingly collect data from anyone under 16. If you believe we have, write to privacy@omnisio.app and we will delete it.

At 16 and 17, a parent or legal guardian is involved — on the contract side. The membership itself is concluded with them (Terms §1.3), because a paid annual contract that includes a device is an obligation a minor cannot lawfully take on alone. The same person confirms the consent for processing wellness data described in §4.1, from an e-mail address we have verified, and we keep a record that the confirmation was given and when — for no purpose other than being able to show it was obtained.

16 is a deliberate floor rather than a number we were pushed to. It sits at or above the digital-consent age in every EU member state, so Article 8 of the GDPR — the parental-consent rule for children's data — is not triggered by the data side at all, and it is well above the 13-year threshold of the US Children's Online Privacy Protection Act. The parental step above exists for the contract side, which is a different question with a different answer.

The Terms and this page now carry the same number. Until version 2.4 they did not: the Terms said 18 and this page said 16. One document is §1.3 of the Terms, and both now point at it.

20. Security

What is in place:

• HTTPS / TLS for all network communication
• Encryption at rest (AES-256-GCM) for sensitive fields
• Role-based access control
• An audit trail for credential events — API-key and sign-in use (§17)
• Heart signal readings never reaching our servers at all — protection by design rather than by policy (§10)
• Sign-in credentials held on your device in the iOS Keychain, encrypted by the operating system
• A name filter and a human-reviewed moderation queue for Community content (§8)

No system is 100% secure. If you suspect a breach: security@omnisio.app

21. Changes to This Policy

What changed in version 2.16 (3 September 2026). Something shipped, and for the first time in seven versions the change to this page is not a correction to a description of code that was already running. §3.12 described Morning Calibration as designed and switched off through every version up to 2.15. The code that runs it is written and deployed, and one condition still stands between it and the switch — the VERBIS registration in §3.12 — so no morning is measured from anyone yet. We are rewriting the section now rather than on the day the switch is thrown, so that what it describes is checkable before it starts. That section is rewritten from the code rather than edited: what the phone measures, that one of the four measurements is an angle and not a ratio as every previous version called it, the eleven further fields a morning carries beside those four that no version listed at all, what a refused morning does and does not leave behind, the 24-month retention and the read-back on erasure. The rule version 2.12 added still governs it — not “does the private state leave?” but “what does this payload say about this member that the section does not name?” — and applying it to a section about a face is what surfaced the eleven fields and the angle.

One of the three conditions §3.12 set for opening the switch is still unmet: the VERBIS registration does not yet carry the category. That is written into the section itself rather than left for a reader to notice, and the feature stays closed in the server configuration until it is filed.

What changed in version 2.15 (27 August 2026). Nothing new shipped. Version 2.12 wrote the AI workout plan row's largest correction — that the example session we hand the model is built out of your wellness figures and carries your recovery score — and nothing since re-read it. Measured again against the deployed code, that row is right about every member we have measured something for, and says more than is true about the member we have measured nothing for.

• §13.1's AI workout plan row said your recovery score leaves, or your sleep score under that name. Where we hold neither, a fixed sixty-five leaves under that name instead. It is the same number for everybody in that position, so it is not a figure about that member's body at all — and the session's length, its effort ceiling, the readiness line and the ranking on every candidate exercise are worked out from it exactly as they would be from a real score. The row now says so. This correction runs in the unusual direction: the page was describing a transfer larger than the one that happens. It is a wrong sentence either way, and a member who has recorded nothing is entitled to know that the number standing in for her body in that request is not hers.
• The figure itself is sent on purpose, and that decision belongs on this page rather than in a code comment. A plan cannot be sized honestly without some indication of how well-recovered you appear to be, so the readiness indicator stays in what we send and is described here instead of being quietly removed. What this page owes you is an accurate description of it, in the same category language the rest of §13 uses: a figure our own engine derived from your readings, sent to an AI processing provider identified here by category.
• What this does not touch. The rest of the row was re-read against the deployed code and stands: the strain we aim at, the training goal, the week of the cycle and what we call it, the session's length and effort ceilings, the effort target on every movement, our confidence in the plan, the list of our own records drawn on, the readiness line at sixty, the low-sleep and forced-deload notes, the no-history note, the low-recovery line at forty and the active-recovery title. Pregnancy and postpartum are still held back on the terms this row already describes. No other row of §13.1 and no bullet of §13.2 changes.

What changed in version 2.14 (27 August 2026). Nothing new shipped. Version 2.8 withdrew a claim that we had reviewed our AI provider's data processing agreement, and recorded obtaining it as an outstanding action. The document has now been obtained and read, and §13.5 says what it contains — including the parts that do not help us.

• §13.5 now describes the processing addendum instead of the customer relationship. It is the provider's standard, openly published document, incorporated into the terms we accepted rather than negotiated for us, and the version read is the one dated 31 July 2026. The section lists what it settles — processing only on our instructions, confidentiality, a written security programme with named controls, breach notice to us without undue delay, deletion after termination with a certificate on request, audit through report summaries and an on-site right on 30 days' notice, sub-processor notice of 15 days with a 10-day objection window, and the EU Standard Contractual Clauses incorporated for transfers, with UK and Swiss variants.
• Four things it does not do are written down beside the four it does. It names no sub-processor — the attachment meant to list them points at an address that served us no names — so the second company in the chain (§13.3) is still unidentified. It contains no clause excluding the use of our requests for model training; that exclusion comes from the published terms of the tier we buy and not from this document, and it expressly permits the provider to process deidentified data to improve its service. It names no country and makes no residency promise. And it provides for retention until the agreement ends.
• §13.3's retention bullet is corrected by the same reading. It described the provider's retention as "standard processing of the request". The document says the provider retains what we send until our agreement with it terminates. The bullet now says that, and points at §13.5.
• What this changes for Turkiye: nothing, and the section says so. The Standard Contractual Clauses are the European mechanism. Article 9/4 of the KVKK wants one of its own, and this addendum is not one. §4.1 of the KVKK disclosure still records that we hold no such contract for any processor, and this version does not touch that.
• The withdrawn sentence is not restored. It claimed satisfaction with GDPR Article 28 and KVKK Article 12. What replaces it is a description of a document rather than a verdict on it.

What changed in version 2.13 (27 August 2026). Nothing new shipped. Every version since 2.8 has carried two claims about your name on the blood test path that cannot both be true, and this is the version that noticed.

• §13.2 promised, without exception, that your name is not sent. §13.1's own blood test row has said since version 2.8 that it is — printed on the page you upload, where the laboratory put it there. The two sentences have stood roughly forty lines apart since the AI disclosure was first built, and this is the first version to check one against the other. §13.2 now says which five paths keep that promise and names the one that does not, rather than promising it of all six.
• The blood test row also understated its own leak by one line, unrelated to the page's content. "Nothing else goes with it today" was not quite complete: the file's own name — the string your phone or computer gave it, not anything printed on the document — is sent as a separate line of text alongside the request. A file named the way a Turkish laboratory's own download usually is, after the patient it belongs to, carries a name that is not on the page at all. The row now says so, as a second and separate route by which your name can leave on this one path, distinct from the printed-page route above it.
• What this does not do. Nothing here claims Omnisio redacts, reads or otherwise strips a name out of a document before sending it — no such capability exists, and this page will not describe one that doesn't. It also does not touch the other five rows or the rest of §13.2's list: your email address, your phone number, your precise location, your IP address, your heart signal readings, your profile picture, government identifiers and other members' data are still not sent, on any path, and nothing found here says otherwise.

What changed in version 2.12 (27 August 2026). Nothing new shipped. Version 2.11 corrected three rows of §13.1 by asking one question of each — does a pregnancy or postpartum record leave? — and every pass before it asked that same question. None of them asked what the rest of the request says about your wellness, and the AI workout plan row was wrong because of it.

• §13.1's AI workout plan row named four things that leave. It left out the example session, and that session carries your recovery score. The row read "what you asked for, the category you chose, the candidate exercises our own engine has already narrowed the plan down to, and a neutral movement constraint". We also send the plan our own engine had already written for you, so the model has something to improve rather than invent — and that plan is built out of your figures. Your recovery score goes as a number; so do the strain we were aiming at, your training goal, the week of the cycle, the session's length and its effort ceilings — all three computed from that score — a written verdict on your readiness, and notes saying that your sleep score was low, that a deload was forced by hard recent sessions, or that you have no history with us. §4.1 of this page treats figures about your body as special-category data, and a recovery score is one of them. The row now lists them.
• The other five rows were put to the same question, and two of them were short as well. The Today's Insight row did not mention the confidence we place in your ageing estimate. The Deep Health Report row summarised its payload as "the computed metrics and the trends behind them" without saying that those include your recovery and readiness scores with their zones, a baseline for every vital, the list of metrics we could not measure at all, and any watch-out our own servers had already flagged — a run of nights below ninety per cent blood oxygen, with the dates and the readings. Both rows now say so. The Food Scanner, blood test and AI Concierge rows carry no figure derived from your wellness data at all, and are unchanged.
• The scrub that keeps the pregnancy and postpartum lines back does not keep anything else back, and the row now says which is which. It matches words. That is why a session title, a coaching cue or a safety line naming one of those states stays on our side, and why the recovery figures sitting beside them do not. It also deletes a line rather than replacing it, so a postpartum member's example arrives one line shorter than everybody else's — the argument version 2.11 made about the shape of the instructions applies to the example plan too.
• The rule this version adds. Versions 2.9, 2.10 and 2.11 each measured a row against the question the version before it got wrong. Asking "does the private state leave?" three times running will never find a row that under-states an ordinary wellness figure. From here every row is measured against a second question as well: what does this payload say about this member's body that the row does not name?

What changed in version 2.11 (27 August 2026). Nothing new shipped. Version 2.10 checked the AI Concierge row against its own service and concluded that a recorded postpartum period changes only the wording there. That conclusion was wrong, and it stood inside the most sensitive disclosure on this page.

• §13.1's AI Concierge row said neither the fact of a postpartum record nor the number of weeks reaches the provider. The fact of the record does. It is written into the instructions attached to your own message, in a sentence stating that you are postpartum, and again in the instructions above them, which name recent birth, the end of a pregnancy and a loss. The row now says so.
• The same row called those instructions "fixed sentences". They are not. Four rules are attached only when they apply to you, so the shape of the request itself carries two more things: whether you have recorded that a baby is at home — where you have not, a rule appears that names miscarriage, stillbirth, neonatal death and termination — and whether physical-recovery support is switched off for you, which is your own setting. A rule that appears only when it applies discloses the thing it is conditioned on. The half that was true is kept rather than deleted with the rest: the number of weeks is still not sent on this path.
• The Today's Insight row was measured again. Its account of the data holds; its account of the instructions did not go far enough. Two of the rules on that path are conditional as well, on the same fact about a baby at home, and the row now says that too. That measurement asked about the instructions only; version 2.12 above adds the ageing-estimate confidence it was not looking for.
• The AI workout plan row said the tokens that do cross have "nothing in them that says why". They do. One movement class is added on that path and no other, and the single intensity ceiling is computed from the phase and from whether the birth was surgical, assisted, complicated or undisclosed. The state, the week count, the phase and the delivery route are still not sent as fields — but the row no longer claims that what remains says nothing. That row was still short of the mark, and version 2.12 above corrects it: the example session sent with the request carries your recovery score and the figures derived from it.
• The Deep Health Report, Food Scanner and blood test rows were re-read against the running code and are unchanged. The report path still drops the two fields that would name the state before the extract is built, and neither of the other two has any pregnancy or postpartum handling in it at all. "Unchanged" was true of the question asked, and version 2.12 above changes the Deep Health Report row on a different one.
• The rule version 2.10 wrote down was right, and it was applied too narrowly. "Two rows sharing a sentence do not share a behaviour" is what stopped a correct row from being broken. What it did not do was make anyone measure the second row as carefully as the first: the Concierge row was checked against the part of the service that builds the instructions sent as system text, and not against the part that builds the message sent as yours. The rule now reads: measure every row against every place its own service assembles a request.

What changed in version 2.10 (27 August 2026). Nothing new shipped. Version 2.9 corrected the tense of §13.1 and left the same table under-stating three transfers — each one a row that named something smaller than what the running code actually sends.

• §13.1 said a postpartum record shapes the instructions. It travels in the request as well. The Today's Insight row read "the instructions sent with the request reflect that", which invites a member to conclude that a recorded postpartum period only changes how her card is worded. The request itself carries the fact of the record and the number of whole weeks since it began, plus three internal markers about our reading of her baseline. A count of weeks dates the end of a pregnancy to within a week, and §4.1 of this page calls a postpartum record special-category data. The row now says both halves. The AI Concierge row carries almost the same sentence, and it was checked on its own rather than assumed to be wrong too: there the instructions really are the whole of what changes, so that sentence stays exactly as it was. That check was itself wrong, and version 2.11 above corrects it: the fact of the record is in the Concierge request too, and those instructions are not fixed.
• §13.1 summarised the Today's Insight payload as four figures, and it carries far more than four. "Recovery, HRV, sleep, activity" left out the readiness score, the ageing figures and the pace of ageing, the stress score with last week's average beside it, the overnight blood-oxygen and sleep-regularity blocks, the hour-by-hour step breakdown, and seven further vitals — each vital sent with its average, its lowest and its highest as well as today's reading. The row now lists what is in there.
• §13.1's Concierge row described two requests and not the data attached to the second one. When your question is one that needs your own numbers, up to ninety days of your recorded readings — as many as five thousand of them, each with its value, its unit, its time and the device it came from — go out with it. That row also said the content of this path is decided by you rather than by us. It was true of your text and wrong about the readings, and the correction goes against us.
• Two rows are strengthened rather than corrected, and both changes are in your favour. The AI workout plan row named only pregnancy as the state deliberately withheld from the model; a postpartum record is withheld on the same terms, down to scrubbing those words out of the example plan we send. The Deep Health Report row said nothing about postpartum at all, and now says the state is dropped before the extract is built.
• The Food Scanner and blood test rows were re-read against the running code and are unchanged. Neither path has any pregnancy or postpartum handling in it, and neither sends anything beyond what those two rows already describe.

What changed in version 2.9 (27 August 2026). Nothing new shipped, and this time the correction is about tense. Version 2.8 rebuilt §13.1 by reading the code — but it read the code on a developer's disk rather than the code that is running. Two of the six rows therefore described, in the present tense, data that has never left our servers.

• §13.1 told you we send profile facts that we do not send. The Today's Insight row listed your reference sex, country, height, weight, stated fitness level and health goals, and the Deep Health Report row carried the same list by reference. What actually leaves on those two paths is your age and nothing else off your profile. The wider projection exists as written, undeployed code. A privacy policy has to describe what is running, so both rows now say what is sent, name what is not, and describe the wider version the way this page already describes every other built-and-unshipped thing: as something that starts on the day it ships, with the row rewritten in that release. The Today's Insight row also claimed a recorded pregnancy shapes the request; only a recorded postpartum period does today.
• §13.1's blood test row was right about the file and silent about the rest. It said the laboratory report file itself is what leaves — that is still exactly true — and it did not say that a change already written would send your profile and a summary of your own earlier blood tests with it: for up to three previous reports, each biomarker's name, value, unit and draw date. That would make one upload carry your prior laboratory history, which is the sort of thing a member should hear before it starts rather than in the release notes afterwards. The row now says both halves: what leaves today, and what is built and not deployed.
• The other four rows were re-read against the running code and are unchanged. Food Scanner, the AI Concierge and the AI workout plan send exactly what §13.1 said they send. In particular the workout path still does not send pregnancy status or trimester, and the Concierge still carries no profile facts at all.

What changed in version 2.8 (27 August 2026). Nothing new shipped. This version exists because an audit of what this page says against what the code does found statements that were wrong in both directions, and the largest of them was an AI disclosure that named two features out of six.

• §13 was a disclosure of two AI features when there are six, and that is the correction this release exists for. The section said Omnisio sends "the following data" for "Today's Insight, Food Scanner" — a closed list. Four transfers were undisclosed: blood test analysis, the Deep Health Report, the AI Concierge and AI workout plans. Two of those carry more than either of the disclosed ones: the blood test path sends the laboratory report file itself, with every value and every name printed on it, and the Concierge sends whatever you type about your own health. §13.1 is now a table of all six, saying for each what actually leaves. §4's purpose table said the same two names and now names all six. Nothing about what the app does changed; what changed is that the page now describes it.
• §13.2 loses a line, and losing it goes against us. "Medical history, medications" was on the list of what we do not send. Biomarker values off a clinical report are medical history, and they leave as the whole report; the Journal's fixed list of behaviours includes taking medication, and a journal entry does reach an AI feature you consent to. The line is deleted rather than softened.
• §13.3 stops describing a second company we cannot name. It presented a "model-routing infrastructure provider" as a distinct sub-processor and gave its logging and training practices. Omnisio holds credentials with one AI company. What we can see from our own code is that the endpoint we call is a routing endpoint taking a model name as a parameter, so the request goes onward to whoever runs that model. That is now what the section says. Naming a company on the strength of an endpoint name would be a fact we do not have.
• §13.5 withdraws a claim that a review happened. It said we had reviewed the providers' data processing agreements and were satisfied they meet GDPR Article 28 and KVKK Article 12. We are a paying customer of the provider; that is not a signed processing agreement, and we cannot point at one. The sentence is gone, the customer relationship is what is stated instead, and obtaining the document is recorded as an outstanding action rather than described as done.
• §4.1 and §13.4: a consent audit trail was claimed for consents that had no server-side record. §4.1 said "AI features and the Deep Health Report" share one versioned, append-only ledger entry. Only the Deep Health Report does. For the other five features the consent is asked for in the app and the answer lives on your phone alone; our servers do not today refuse a request that arrives without it. Both sections now say so, including the part that is uncomfortable: a record only a handset holds is one a reinstall erases and one we could not produce if you asked. What has been built to close it — a ledger type, a migration that preserves the moment you actually consented, and a server-side refusal behind a switch that is off — is described in §13.4 as built and not switched on, in the same words this page uses for everything else in that state.
• §4.1: the ledger's three consent types were the right count with the wrong contents. Version 2.7 listed them as the Deep Health Report one plus two Morning Calibration ones. The two Morning Calibration types became one when the skin-tone question was removed, and a commercial electronic message type had been added. Three all along, and not one of the named three still correct. A count that stays right while its contents change is worse than a count that goes stale, because it survives the obvious check — so the box now lists the types rather than counting them.
• §3.12: the optional skin-tone declaration is gone from the product and from this page. It has been removed from the design, the interface and the ledger, along with the per-band comparison it existed for. Nothing in Morning Calibration measures colour, so nothing needs a declared tone.
• Sentry never existed here, and this page named it in four places. "Sentry / crash reporting" in §15, crash logs in §3.8, a "diagnostic and crash analytics" purpose in §4, and a 90-day period in §18. There is no crash-reporting, analytics or telemetry component in the app or on our servers — not the one named, not any other. All four are removed. §15's own rule reads back at us here: announcing a recipient that does not exist is as wrong as hiding one that does.
• §18: a 36-month inactivity deletion was promised and does not exist. The wellness row said "until you delete your account (or 36 months of inactivity)". Nothing performs it; core health data carries no expiry at all. The promise is removed rather than quietly left unkept, and it is recorded here as removed. Building an inactivity sweep is a product decision and this page will not create one by describing it.
• §16.1 contradicted §16.2 on the same screen. §16.1 said processors are identified "by category rather than by trade name"; §16.2, four paragraphs later, named Germany, a cloud region and a city. The rule we actually follow is now written down — name what has been verified, describe by category what naming would overstate — and Railway and MongoDB Atlas are named, as the KVKK disclosure already named them. The Frankfurt claim stays, with its source stated: it comes from our architecture documentation and a hostname check, not from the live cluster configuration, and re-confirming it is an open action. The Turkish cross-border analysis it feeds does not depend on the answer, because no adequacy decision exists for any country.
• Recipients that were never listed. Expo's push service receives your device token and the notification itself before Apple does — §15 named only Apple. Cloudflare R2 holds profile pictures in a public bucket and, for 7 days, the archive a data export produces: a single file containing everything we hold about you, which no section of this page had ever mentioned. Both are added to §15 and to §16.2's list of United States recipients. §17 now describes the archive at the point where you exercise the right that creates it. And §15's Firebase row said "email, sign-in token" while the account there holds your email address, phone number, display name, avatar and sign-in provider.
• §3 was thinner than the Turkish KVKK disclosure, which is the reverse of what the top of this page promises. Categories the system collects and this section did not list: blood test reports and their biomarker values (now §3.13), the ongoing nutrition log as distinct from the meal photo (§3.14), files imported from Whoop, Oura, Garmin or Apple Health (§3.15), and — added to §3.2 — oxygen saturation, workouts, body composition, and pregnancy and postpartum records, which Turkish law counts as both health data and data concerning sex life.
• §20 claimed security controls that do not exist, and contradicted our own KVKK disclosure. It listed multi-factor authentication, annual third-party penetration testing, bcrypt password storage and audit logging of all administrative actions. The KVKK disclosure has said since 9 August 2026 that the first two are not in place; this page went on claiming them. The list now describes what is actually there, and names what is not.
• §17 and §18: three records that survive account deletion had never been described. The erasure receipt that proves the deletion happened, the credential audit trail that makes abuse against other accounts visible, and the membership grant row that is emptied rather than deleted so that a later reconciliation cannot rebuild your membership against your address. All three are legitimate; none had been written down. §18 also gains the export archive (7 days), the raw device-sync payload archive (30 days), and one summary row for the infrastructural clocks that are not about you.

What changed in version 2.7 (4 August 2026). Direct sales and the family plan are open. Version 2.5 wrote a promise into §3.9: that the box saying none of this was collected would come out in the same release as the code that starts writing these records, and not a day earlier. This is that release, and this entry exists so the promise is visible as kept rather than quietly dropped.

• Corrected again inside 2.7: the consent ledger holds three types, not one, and a new §3.12 says what the other two are for. §4.1 said the ledger accepted exactly one consent type. It accepts three: the Deep Health Report one, and two belonging to Morning Calibration — a facial-measurement study and an optional skin-tone declaration. Nothing about that changes what is collected, and that is the whole difficulty with the old sentence: it was wrong in the direction that flattered us. So the harder statement is now written in both halves — the ledger accepts three, and only one of them is in use, because the surfaces the other two exist for are switched off at the server and every call to them is refused. §3.12 is new and describes the measurement while it is still closed: four geometric ratios computed on the phone, an optional skin-tone band, no photograph reaching us in any encoding, and the three conditions that have to be true together before the switch is turned on. Morning Calibration is described on the website from this release onwards, and a feature the public pages describe has no business being absent from the policy.
• Corrected again inside 2.7: what account deletion does to a family plan — five places, and one of them was the worst kind of mistake this page can make. The deletion code changed and the text still described the old behaviour, wrongly in both directions. Where we said we keep something, we delete it. A member who deletes their account now has their address taken out of the buyer's order as well (§14.6, the former fifth limit in §17, §18) — and the one-click objection link in §17.1 reaches the buyer's order too. That last one is the correction that mattered: §17.1 told a person we could not do something for them that we in fact do, and no sentence on this page is worse than that one. Where we said we delete something, we keep it. A guest order is now deleted with the account whose verified address placed it — except a family plan that took money, which outlives its buyer so that between three and ten other people's memberships run to the end of the term already paid for (§14.7, the fourth limit in §17, §18). §14.6 gains the other half of that: what those members keep, and that they are told the end date once now and again 30 and 7 days before it, in a message that never mentions the person who left. The precondition none of these sections had written down is now stated in §17: all of it is keyed on a verified email address, and where an account proves none, none of it runs. The card box under §3.9 has been brought under the same rule as the five rows above it — no membership here renews itself, so no renewal token is stored, and saying otherwise described a mechanism that does not exist.
• Corrected again inside 2.7: a fifth row, and three places that mirrored it. The correction below fixed four rows of the §3.9 table and missed the shipment row, which said we hold a tracking number and a delivery status. We hold neither: the tracking field on an order record is empty, the shipment list beside it is empty, and no carrier system is connected to ours — a parcel is dispatched and chased up by a person. The same present tense had survived in three more places: the delivery paragraph in §14.2, the accounting and e-invoicing row in §15 (no accounting provider is connected and we issue no invoices, which §18 already said on its own row), and the card box under the §3.9 table, which described a transaction reference, an outcome and a renewal token arriving from a provider that is not connected. All of them now say what is true today and name the day the rest begins. No row was removed.
• Corrected inside 2.7: four rows of the §3.9 table described data we do not collect. The first cut of this release listed invoice details, a payment reference, payment attempts with the provider's raw notification, and a currency conversion stamp as things an order record holds. It holds none of them. No payment provider is connected — an order is recorded, nothing is charged, and a person takes it from there; the checkout form never asks for an invoice field and the order schema rejects one; the conversion code is never called. All four rows now say so, in the same words the table already used for the family member's delivery address. They stay in the table rather than being deleted, because the fields are built and dropping them would let the same gap reopen the day direct payment goes live. §15 and §18 repeated the same four claims and were corrected with them. The box at the top of §3.9 requires that a row describing something built but not yet collected must say so — this is that rule applied to the release that wrote it.
• The §3.9 warning box is gone and the section describes the present. Eleven data categories that had never been described are now in the table — the heaviest of them other people's email addresses. A family plan is the first thing Omnisio has sold that asks a customer for someone else's personal data, and the policy could not stay silent about it for a single release.
• Family plans have their own section (§14.6): what the person who paid sees (the status of each place — never a name, never an address, never any wellness data), what the invited person is told and on what legal basis (legitimate interest, not consent, because nobody can consent on another person's behalf), the 90-day life of an address that is never claimed, the 3-to-10 range, and the rule that an active membership is not taken away in the middle of a term.
• Ordering without an account is described for the first time (§14.7), including the part that is easy to get wrong: account deletion does not reach a guest order. This page had no concept of a buyer without an account, and should have had one before the first such order was possible.
• §17 goes from three limits on erasure to five, and gains §17.1 for someone who was invited and never signed up: what we hold, where we got it, how long, and how to end it in one click without an account.
• §18 is now by field rather than by row. An order holds a commercial record and, next to it, the email address of a person who may never become a customer; those cannot share a period. The row that used to say an order is not deleted with your account now says the opposite, because that is what the code does: the ten-year clock in Article 82 belongs to an invoice and the books behind it, and no invoice is issued yet. When the ten-year clock does start it is stated correctly for the first time: under Article 82/6 of the Turkish Commercial Code it runs from the end of the calendar year, not from the order date. §14.4, §14.7, §17 and §17.1 were corrected in the same pass, because four sections were repeating the same wrong sentence.
• Two corrections to §15. A transactional email provider has been added — every invitation passes through it carrying the recipient's address and the buyer's full name, and no existing category covered an email delivery service. And the separate Russian payment provider has been removed: there is none. Cards issued in the Russian Federation are refused, and announcing a recipient that does not exist is as wrong as hiding one that does.
• §3.11 no longer claims there is no third-party request on any page of this site. The store, checkout, order, home and Omnisio Team pages load their typefaces from a third-party font host, which sees an IP address. It sets no cookie and it is not tracking, but the old sentence was wider than the truth. The font host is now listed in §15.
• §16.3 stops saying the Russian localisation question is under review and states the exposure instead. That sentence was honest while nothing was collected. It stopped being honest the moment a Russian-language checkout could write a Russian resident's email address into a database outside Russia. We take no compliance position, because we have none to take — the section now gives the facts, the open question and the decision that is pending, rather than a reassurance.
• Everything version 2.5 said about "not collected" is superseded. The 2.5 entry below is kept, because a changelog is a record and not a description of the present. Where it says the order table has no writer, that stopped being true in this release. Its statutory retention entry is superseded as well: it says invoices and order records are not deleted with your account, and today they are — the reason is in §18.

What changed in version 2.6 (30 July 2026). Two corrections. §19 said the app's own onboarding still admits users from 13. That stopped being true when the age gate moved: the app now refuses a date of birth under 16, and purchase is closed under 18. The section now describes the gate that ships and names the one thing still missing — verified parent or guardian confirmation for 16- and 17-year-olds. Separately, editorial notes that were never meant to be published — a working-status banner and internal review markers — were removed from the rendered page. No right, period or obligation changed.

What changed in version 2.5 (29 July 2026). Every change in this release is a correction: version 2.4 described a product that does not exist yet, and the fix in each case was to describe the one that does.

• Wellness-data consent (§4.1) — 2.4 said we ask for explicit consent before processing any wellness data and record it. We do not: as the ledger stood in July 2026 it accepted one type, the Deep Health Report one, alongside the Community metric shares. The two consents that do exist are now described exactly, and the missing one is marked as missing instead of claimed. Superseded on the count only: the ledger has since gained the two Morning Calibration types, neither of which is in use — §4.1 carries the present figure.
• Purchase, delivery and billing data (§3.9, §14.4) — none of it is collected. Memberships are sold through the App Store; the order table in our database has no writer. The section now says so at the top, and stays as an advance description of direct sales rather than a description of the present.
• Statutory retention (§17, §18) — 2.4 said invoices and order records survive account deletion. They cannot survive it: they do not exist, and account deletion currently purges the dormant order table along with everything else. Corrected, with the future position kept and clearly labelled as future.
• The wearable's CE marking (§6) — 2.4 stated the device was CE-marked for consumer wellness use. That is a regulatory claim and the certificate has not been verified, so it is removed and the field left open, matching what the Terms already said.
• Minimum age (§19) — this page said 16 while the Terms said 18. There is now one number, 16, defined in Terms §1.3, plus the parent-or-guardian step that the contract side requires between 16 and 18.
• Which language binds (top of page) — the Turkish, Russian and Spanish versions of this page each said the English version was the legally binding one, while the Terms said the Turkish text binds consumers in Turkiye. Two documents cannot answer that question differently. All eight documents now carry the Terms' rule.

What changed in version 2.4 (29 July 2026). Omnisio began selling a membership that includes a device, and shipping a device requires data that an app on its own never needed. This version documents that, and corrects three things the previous version had wrong:

• Purchase, delivery and billing data (§3.9, §14) — name, delivery address, phone number, invoice details, order history, payment reference, device serial number and shipment tracking, each with its purpose, legal basis, retention period and recipient. Your card number is not among them and never was.
• Statutory retention (§17, §18) — invoices and order records are kept for a legally fixed period and are not deleted when you delete your account. The previous version implied that everything went. That was wrong, and saying so plainly is the point of this release.
• Wellness data is treated as health data (§4.1) — special-category under KVKK Article 6 and GDPR Article 9, processed on explicit consent rather than on the contract. Version 2.3 based it on the contract, which is not a sufficient condition for special-category data.
• Device replacement requests (§3.10) — a category of data the product already collected and this policy had never described.
• Storage location (§16) — version 2.3 named a specific data centre that does not match how the service is deployed. The claim has been removed rather than reworded.
• The website (§3.11) — it sets no cookies and runs no analytics. Said out loud, because a privacy policy that stays quiet about it invites the assumption that something is being counted.

What changed in version 2.3 (25 July 2026). One change, and it does not change what happens to your data:

• AI recipients described by category (§13, §15) — our AI processing provider and its model-routing sub-processor are now identified by category rather than by trade name, as GDPR Article 13(1)(e) permits. What we send, what we do not send, that AI features are opt-in and revocable, that your data is not used to train models, the retention position and the data processing agreements behind them are all unchanged.

What changed in version 2.2 (25 July 2026). Two corrections, both made because the published text did not match what our systems actually do:

• Subscription records (§18) — version 2.1 said we keep subscription receipts for 7 years. We do not: the subscription records we hold are deleted with your account, and the purchase record itself is held by Apple and RevenueCat under their own policies. The retention row now says so.
• In-app paths (§17) — corrected to the labels the app actually uses, and both routes to the same delete control are now named. The Data Deletion page was rewritten in the same pass: it described a category-by-category deletion picker, an emailed reference number and a genetic-data destruction process, none of which exist.

What changed in version 2.1 (25 July 2026). That release documented features that were not covered by version 2.0:

• Community (§7) — what other members can see, per-metric opt-in that is off by default, friends, teams, challenges, the activity feed, and the fact that there is no chat.
• Reports, blocks and moderation records (§8) — what we store, that staff review it, and that these records outlive accounts.
• Precise location during runs (§9) and Motion & Fitness for cadence and elevation.
• Heart signal readings (§10) — stored on your device only.
• Journal entries (§11).
• Camera and photo library (§12) — meal photos and profile pictures.
• Retention (§18) and rights (§17) extended to cover all of the above; in-app paths corrected to More → Privacy & Trust.

No third-party recipient was added in 2.1. Community, runs and journal data are handled entirely by Omnisio.

We will notify you of material changes via:

• In-app banner on next launch
• Email to your registered address (if material)
• Updated "Effective Date" at the top of this page

Continued use after notification constitutes acceptance.

22. Contact

• General privacy: privacy@omnisio.app
• DPO inquiries: dpo@omnisio.app
• Security disclosures: security@omnisio.app
• KVKK requests: kvkk@omnisio.app
• Phone: +90 532 666 00 77
• Postal: Oney Finansal Danışmanlık Turizm ve Dış Ticaret AŞ, Esentepe Mah. Kore Şehitleri Cad. Yonca Apt. No:1-3 Daire 6, 34394 Şişli/İstanbul/Türkiye

Last updated: 3 September 2026 · Version: 2.16