Legal

Privacy Policy

Eira holds some of the most sensitive data there is, so this is written in the same detail we would want if it were ours. The sections that answer most questions are 6 (what the AI sees), 8 (who else touches your data), 10 (how long it is kept, and what deleting your account actually does) and 12 (your rights). Health data also has a policy of its own, at Consumer Health Data. Version 1.5, effective 23 August 2026.

1. Who we are

1.1 The controller

Codes L.L.C., a limited liability company registered in the Republic of Kosovo at Kodra e Diellit, H 1/2, Nr. 22, Prishtinë, company number 810858003 (“Eira”, “we”, “us”, “our”), is the controller of the personal data described in this policy. That means we decide what data is collected and why.

1.2 How to reach us about privacy

Privacy questions, data-subject requests and complaints reach us through the contact form, or at legal@eira.coach. A person reads both.

1.3 What this policy is not

Eira provides wellness guidance, not medical advice. Eira is not a healthcare provider, and this policy is not a HIPAA notice — Eira is not a HIPAA covered entity or business associate. Health information you give a wellness app is generally outside HIPAA and inside consumer privacy law, which is what this policy addresses.

Two of those consumer laws are worth naming here rather than leaving to a later section. California’s Confidentiality of Medical Information Act was amended in 2022 to reach a business that offers a mobile application designed to hold medical information, whether or not it has anything to do with a hospital or an insurer; Eira is that kind of application, and §12.3 sets out what we take that to mean. And Washington’s My Health My Data Act requires a health app to publish a separate consumer-health-data policy: ours is at Consumer Health Data, and it stands on its own rather than pointing back here.

2. Scope

2.1 The app

This policy covers the Eira iPhone app, its Apple Watch companion, its widgets, complications and Siri/App Intents surfaces, and the backend service behind them.

2.2 The website

It also covers eira.coach. The website is a marketing and legal surface only: you cannot create an account or log food on it.

2.3 What it does not cover

Apple. Your App Store account, your payment method and your Apple Health data on your device are governed by Apple’s privacy policy. We never see your Apple ID password or your card details.
Third-party sites linked from ours or from the app (for example, a crisis helpline’s own website).

3. What personal data we collect

Categories marked [Art. 9] are special-category health data under the GDPR and UK GDPR, sensitive personal information under CCPA/CPRA, sensitive data under the Virginia-model state laws, and consumer health data under Washington’s My Health My Data Act. They carry the strictest handling rules in this policy.

3.1 Account and identity

A user identifier issued by our authentication provider when you use Sign in with Apple. This identifier is your account key — we hold no separate mapping.
The email address Apple relays to us. If you chose Apple’s Hide My Email, this is a private relay address and we never see your real one. Your email is display-and-export only; we never use it to look up your account.
Your time zone, the hour at which your day starts, and account timestamps (created, onboarded, trial start).

We never receive or store a password.

Your date of birth. The first thing Eira asks you for is your full date of birth, and it is collected for exactly one purpose: Eira is for adults, and we have to be able to check that (§13). The check runs on our server, not on your phone, and the date itself is kept so that the answer cannot be quietly re-derived from something else.

It is the full date, not the year. A day and a month are what an age check needs to be right on the day it matters, rather than eleven months either side of it. It is held separately from the optional year of birth in §3.4, which exists for a different reason — though not independently of it: writing that year writes over this date, and clearing your body measurements clears them both (§5.2).
The check is write-once, not the date. The date can change — the year-of-birth field in About you writes over it (§3.4), and “Remove your biometric data” clears it (§5.2). What cannot be re-taken is the check itself: it is submitted once and a second submission is refused, and only that submission moves the age gate. A figure typed into any other field is not an attestation of your age. An adults-only rule a person could simply answer again would not be a rule. §15.1 explains the decision it feeds and how to contest it.
If the check went against you, a person will look at it. Write through the contact form or to legal@eira.coach (§12.5, §15.1). That is a right rather than a favour, it does not require you to get past the block first, and it is why we answer that mailbox.
It is kept for as long as your account exists and deleted with the account (§10). It is in your data export (§12.1), it is never sent to an AI provider, and it is never written to a log line.

3.2 Your food record [Art. 9]

Meals and their times, meal slot, and how each was logged (photo, voice, barcode, search, manual, repeat, Watch, widget, Siri).
Per item: the food’s name, the nutrition database it was matched to, portion in grams, and the resulting calories, protein, carbohydrate, fat and fibre, plus eight micronutrients (sodium, potassium, calcium, iron, magnesium, vitamin D, vitamin C, B12).
Meal photos you take, and label photos when you teach Eira a product.
The structured output of the AI analysis of a photo (what the model identified, its portion estimate, its confidence, its stated assumptions).
Your corrections — what the model said, what you changed it to, and how you changed it. We keep these because correcting the estimate is how Eira gets better at your food. See §6.5.
Recipes you build, and their ingredients.
Water you log, and your water quick-add presets.

3.3 Mood and context of eating [Art. 9 — the most sensitive field in the product]

Entirely optional, off by default, and offered on one screen. If you turn it on you can tag a meal with one or more of eight fixed words (hungry, stressed/anxious, tired, bored, sad, social, celebrating, craving) and add a short free-text note.

Three things are true of the free-text note and are worth stating plainly:

No person reads it, and no AI model is sent it. It is excluded from every aggregate, every AI prompt and every log line by design. The only place it is ever returned is your own data export.
One automated check does read it, and we ask your consent for it. As you save the note, our own server checks its words against a fixed list of phrases that read as distress or as difficulty with eating, so that crisis and eating-disorder support lines can be offered to you underneath the meal you just saved. It is a list of words — not a model, and not a clinician. Its outcome is never stored, never added to your record and never sent to anyone, and the only trace it leaves anywhere is a bare count that the check fired at all — not for whom, and not which of the two it was, so nothing in our logs says anything about you (§11.3). And it never blocks, delays or changes what you logged — the note is saved before the check runs. The same check reads your coaching chat messages, where it can additionally change which of our AI models replies to you (§15). This is named in the consent step (§5.1) rather than left for you to discover.
It is never stored on your device. It lives only on the server, so that the deletion controls that reach the server reach it too. The check above adds nothing beside it, so there is nothing extra to delete: clearing the note, or deleting your account, erases it in the same verified cascade as the rest of your record (§10.1).

3.4 Weight and body measurements [Art. 9]

Your weight over time, entered manually or read from Apple Health with your permission.
Optionally, sex, height and year of birth — collected only because the calorie-estimation formula needs them. The formula needs an age in years, so what it gets is a year; the full date of birth in §3.1 is a separate field, held for the age check and for nothing else — separate in storage, but not insulated from these three. These three are never written to a log line and are never cached on your device, and you can withdraw all three at once without deleting your account (§12.1).

Removing them clears the date of birth in §3.1 as well (§3.14, §5.2). What it does not clear is the age check itself: the date and the verdict are different records kept for different reasons, and while the date goes with the measurements, the verdict and the moment it was taken stay. Withdrawing does not reopen the age question. Everything in §3.1 goes when the account goes.

3.5 Nutrient-floors mode [Art. 9]

If you turn on nutrient-floors mode, we store the fact that the mode is on. It changes what Eira leads your day with — protein, fluid and fibre against daily minimums, for times when your appetite is low — instead of a calorie ceiling.

We treat it as health data. Eira treats nutrient-floors mode as health data and protects it as special-category — whether or not the law strictly requires it. Turning it on says something about your physiological state, and that is enough for us. Our bases for it are in §5: Art. 6(1)(b) contract, with Art. 9(2)(a) explicit consent as the Art. 9 condition, given in the consent step described in §5.1 and withdrawable as described in §5.2.
It is keyed to a need, not to a medicine. We do not ask, and do not store, why your appetite is low or whether you take any medication.
A second setting can ride with it. While the mode is on, you can tell Eira that a clinician has asked you to limit your protein, held as a single yes-or-no field (protein_limit_advised). If you set it, Eira stops leading you toward a protein minimum and points you back to that clinician instead. We store the yes-or-no answer only — never the reason, the condition, or which clinician gave the advice.
What is sent to the AI coaching model. When the mode is on, the coaching model is told that you are eating less than usual and that Eira should lead with floors. It is never told any medication, molecule or diagnosis, because none is held; and the floor figures themselves are computed on our server and are not sent to the model.
Turning it off. What stops is the floors computation; no stored nutrition changes. Leaving the mode also clears the protein-limit setting above back to “not asked”, so that answer does not outlive the mode it was given for.

A field this mode used to hold, and no longer does. Until 11 August 2026, the mode asked which medication you were taking and stored the answer as a generic molecule. That question has been removed, the field has been deleted, and the stored values were erased from our live database on 11 August 2026. Exports you generated before that date still contain whatever was held at the time; and, as with anything you erase, copies may persist in encrypted backups until they age out on the schedule in §10.

3.6 Goals, targets and settings

Goal direction and pace; calorie targets Eira has proposed and whether you accepted or dismissed them, with the arithmetic basis for each; and your display preferences (gentle mode, net carbs, measurement region, pinned nutrient, coaching hour and whether coaching is on).

3.7 Fasting and eating window [Art. 9]

Your chosen protocol and target hours, and each timer you run: when it started, when and why it ended, and which meal ended it if a meal did.

Before the first timer will start at all, Eira asks you to read and acknowledge who an eating window is not for. We store only the fact that you acknowledged it — one boolean, with no record of which of the listed conditions, if any, applies to you. That is deliberate: the acknowledgement is a safety gate, not a health questionnaire, and the answer to “are you pregnant” is not something we want in a database. The boolean is in your export (§12.1).

3.8 What Eira remembers about you [Art. 9 — derived]

This is the product’s core, so it deserves its own line rather than a footnote. From everything above, Eira derives and stores:

Extracted facts — effective-dated statements about your habits, preferences, constraints and life context, each with its confidence and the conversation or log it came from. Facts are superseded, never overwritten, so the history is auditable. Facts touching allergies or medical constraints are flagged as health-sensitive and are never auto-changed by the AI — Eira asks you.
Profile facts — structured, effective-dated profile values.
Weekly profile summaries — deterministic statistics computed in the database, plus a short narrative paragraph written by an AI model from those statistics.
Semantic embeddings — numerical vector representations of session summaries, notes and facts, used to retrieve the right memory at the right moment. An embedding derived from health data is still personal health data, and we treat it as such.

All of it is visible to you on one screen (“What Eira knows about you”), and editable and deletable line by line.

3.9 Coaching conversations [Art. 9]

The daily message Eira writes you (and whether it was sent and opened), your chat messages and Eira’s replies, and derived session summaries.

3.10 Subscription and entitlement state

Which product you bought, its status (trial, active, grace, billing retry, expired, revoked), when it was purchased, when the entitlement runs to, and whether auto-renew is on.

Apple processes the payment. We never receive or store your card number, billing address or any payment credential.

3.11 Device and technical data

Push tokens — an Apple Push Notification token per device, with the platform (iPhone or Watch) and environment. Push payloads carry static text and record identifiers only, never health content, so a notification sitting on your lock screen says nothing about what you ate.
Request metadata — a request identifier and rate-limit counters keyed to your account, kept so the service can be operated and abuse prevented.
Error events — when something crashes or errors, a scrubbed diagnostic event. Local variables from the failing code are stripped before the event leaves the server, specifically so that a stack trace cannot carry your diary out with it.
AI request traces — see §6.4.

3.12 Products you teach Eira

When you scan a barcode Eira does not know and teach it the product (name, brand, nutrition per 100 g, and optionally a photo of the label), that product row is added to a shared catalogue so the next person who scans the same barcode gets an answer.

⚠️ One thing you contribute outlives your account.

When you delete your account, your link to a product you taught Eira is removed, but the product row itself is kept, unlinked from you. This is deliberate: the shared catalogue is how Eira covers regional products no commercial database has. It is the only place in the product where something survives your deletion, and you should know about it before you teach Eira anything.

3.13 Marketing emails

If you join the early-access list on eira.coach, we store your first name, your last name if you gave one, your email address, the record of your consent — the exact wording you agreed to, the version of that wording, and the moment you agreed — and a note of where the signup came from, which for every signup today is the eira.coach website. We keep the consent wording rather than a tick, because consent you cannot evidence is not consent.

Those six things are the record. It is not joined to an Eira account, it says nothing about your health, and it exists for one purpose: to tell you when Eira opens, and after that to send only what you ticked the box for. It is never sold, never shared, and never handed to an advertiser.

We send one note asking you to confirm the address. If you never confirm it, we never write again. Every email after that carries a one-click unsubscribe. Using it stops all mail immediately; we then delete your name and address, and keep only the record that this address asked not to be written to again, because that is the only way to be sure we honour it. You can also ask us to remove it at any time through the contact form or at legal@eira.coach, and the same thing happens.

The list is held and the mail is sent by Brevo, which is a processor for this and for nothing else — it never receives anything from the app, and none of your health data is in it (§8.1).

The lawful basis is your consent, which you can withdraw whenever you like and without giving a reason.

3.14 What we do not collect

No precise location. We never request location permission, and GPS metadata is stripped from every photo before it is stored (§11.2).
No audio. Voice logging is transcribed on your device; the recording never leaves it (§7.3).
No contacts, no photo library scanning, no advertising identifier, no device fingerprinting.
No payment credentials.
No biometric identifiers. No face template, no fingerprint, no voiceprint, no iris scan, no gait or typing signature — nothing in Eira identifies you from a physical characteristic, and no such thing is derived from your photos or your voice. The settings control labelled “Remove your biometric data” is a misnomer we would rather explain than leave you to guess at: what it clears is the body measurements in §3.4 — sex, height and year of birth — together with the date of birth in §3.1, all of them figures you typed rather than biometric identifiers.
No other special-category data — we do not collect race, religion, political opinions, trade-union membership, genetic data, or data about your sex life or sexual orientation.

4. How we collect it

From you directly — everything you type, photograph, speak, scan, tag or choose.

From your device with your permission:

Apple Health, per feature, at the moment the feature is first used — never as a wall of prompts at the start. See §7.
Camera — for photo logging and barcode scanning.
Microphone and speech recognition — for voice logging, processed on-device (§7.3).
Notifications — if you allow them.

You can decline every one of these and keep using Eira with less to go on.

Automatically — the technical and diagnostic data in §3.11, generated by the act of using the service.

From Apple — your Sign in with Apple identifier and relayed email; and subscription status signals when your subscription renews, lapses, is refunded or is revoked.

We do not buy personal data, and we do not enrich your record from data brokers or third-party sources.

5. Why we use your data, and our legal bases

What we do	Why	GDPR Art. 6 basis	Art. 9 condition (health data)
What we doCreate and run your account; authenticate you	WhyYou asked for the service	GDPR Art. 6 basisArt. 6(1)(b) contract	Art. 9 condition (health data)Not health data
What we doCheck that you are 18 or over, from the date of birth in §3.1, before letting you use the service at all	WhyEira is for adults, and a rule we cannot check is not a rule	GDPR Art. 6 basisArt. 6(1)(b) contract — the check is necessary in order to enter into it	Art. 9 condition (health data)Not health data — a date of birth is identity data. This is an automated decision; see §15.1
What we doStore your food, water, weight, fasting and mood record and show it back to you	WhyIt is the service	GDPR Art. 6 basisArt. 6(1)(b) contract	Art. 9 condition (health data)Art. 9(2)(a) explicit consent
What we doEstimate nutrition from a photo, voice note or barcode by sending it to an AI processor	WhyThe feature you invoked	GDPR Art. 6 basisArt. 6(1)(b) contract	Art. 9 condition (health data)Art. 9(2)(a) explicit consent
What we doBuild and maintain the memory: extract facts, summarise, embed	WhyLongitudinal coaching is the product	GDPR Art. 6 basisArt. 6(1)(b) contract	Art. 9 condition (health data)Art. 9(2)(a) explicit consent
What we doWrite daily messages and answer coaching chat	WhyThe feature you invoked	GDPR Art. 6 basisArt. 6(1)(b) contract	Art. 9 condition (health data)Art. 9(2)(a) explicit consent
What we doRun nutrient-floors mode: lead your day with protein, fluid and fibre minimums instead of a calorie ceiling, and hold the clinician-advised protein-limit setting with it (§3.5)	WhyThe mode you turned on	GDPR Art. 6 basisArt. 6(1)(b) contract	Art. 9 condition (health data)Art. 9(2)(a) explicit consent — we treat the mode as health data, because it says something about your physiological state
What we doRead your weight and water — and, if you connect it, your activity and sleep — from Apple Health; write your nutrition back	WhyYou granted the permission	GDPR Art. 6 basisArt. 6(1)(b) contract	Art. 9 condition (health data)Art. 9(2)(a) explicit consent, given through Apple’s own permission prompt and our own consent step
What we doLearn from your corrections to improve your future estimates	WhyCorrecting an estimate is how Eira gets better at your food	GDPR Art. 6 basisArt. 6(1)(f) legitimate interests	Art. 9 condition (health data)Art. 9(2)(a) explicit consent — see §6.5
What we doKeep a copy of a correction in our own evaluation set, so a prompt or model change can be tested before it ships	WhyThis one is our benefit rather than yours, so it is yours to refuse	GDPR Art. 6 basisArt. 6(1)(a) consent	Art. 9 condition (health data)Art. 9(2)(a) explicit consent — asked separately, declinable, and withdrawable without losing anything. See §5.1, §5.2 and §6.5
What we doSafety filtering: check the notes and messages you write in your own words for signs of distress or of difficulty with eating, so support lines can be offered; route those messages; enforce calorie floors	WhyProtecting you from foreseeable harm from an AI health product	GDPR Art. 6 basisArt. 6(1)(f) legitimate interests	Art. 9 condition (health data)Art. 9(2)(a) explicit consent — named in the consent sentence itself (§5.1), described in §3.3, and it stores nothing
What we doManage subscriptions and entitlements	WhyTo bill you correctly and honestly	GDPR Art. 6 basisArt. 6(1)(b) contract	Art. 9 condition (health data)Not health data
What we doSend push notifications you asked for	WhyThe feature you enabled	GDPR Art. 6 basisArt. 6(1)(a) consent (device permission)	Art. 9 condition (health data)Not health data — payloads carry no health content
What we doEmail you about the launch and about Eira, if you asked us to	WhyYou ticked the box	GDPR Art. 6 basisArt. 6(1)(a) consent	Art. 9 condition (health data)Not health data — see §3.13
What we doKeep the service secure; rate-limit; prevent abuse	WhySecurity is a legal duty and a product duty	GDPR Art. 6 basisArt. 6(1)(f) legitimate interests	Art. 9 condition (health data)Not health data — no health values in these records
What we doDiagnose errors and crashes	WhyTo fix what broke	GDPR Art. 6 basisArt. 6(1)(f) legitimate interests	Art. 9 condition (health data)Not health data — health values are excluded by design (§11.3)
What we doComply with legal obligations; respond to lawful requests	WhyWe have to	GDPR Art. 6 basisArt. 6(1)(c) legal obligation	Art. 9 condition (health data)Art. 9(2)(f) where applicable

Explicit consent under Art. 9 is a higher bar than ordinary consent: it needs a clear affirmative act that names the sensitive data and its purposes, separately from a general acceptance of terms. Bundling it into “I agree to the Terms and Privacy Policy” does not meet the standard.

So we ask for it as its own step in onboarding — separate from accepting the Terms, specific about what it covers, never pre-ticked — covering both the processing of health data to provide the service and the sending of it to the AI processors we name, which act on our instructions and for no purpose of their own. We record when you gave it, which version of the consent it was, and the exact wording you saw.

The consent sentence does not promise you no-training terms, and neither does this policy. It says what is true today — that Google and OpenAI act as our processors, on our instructions and for no purpose of their own, and that your name, email address and account identifier are never sent. It stops there deliberately, because a contractual promise we have not finished putting in writing is not one you should have to take from us. §6.3 says exactly where that stands.

The safety check on your own words is named in that consent, not buried here. Reading what you wrote for signs of distress or of difficulty with eating is a different purpose from keeping your diary, working out its nutrition and coaching you — a more sensitive one, and the one you would least expect — so the consent sentence says so in the sentence itself rather than relying on this policy to disclose it. It states what is read (the notes and messages you write in your own words), what it is read for, why (so support lines can be offered), and that the outcome is never stored, never logged, and never a brake on what you log. The full description is §3.3, and the automated-decision position is §15.

One purpose is asked for separately, because it is ours rather than yours. Keeping a copy of your corrections in our internal evaluation set (§6.5) is not necessary to run Eira for you: it makes our next model change safer to ship. So it is a separate opt-in, it is not pre-ticked, and declining it — or withdrawing it later (§5.2) — changes nothing about what Eira does for you, what you can use, or what you pay. Everything else in the table above is what the product needs in order to be the product; this one is a favour, and it should be possible to say no to a favour.

Withdrawal must be as easy as giving it, and it is not all-or-nothing:

What you want to stop	How
What you want to stopApple Health reading or writing	HowRevoke it in Apple’s Health app, any time. Eira keeps working with less to go on.
What you want to stopYour body measurements being held	HowSettings → About you → “Remove your biometric data” — the button’s own label, and a misnomer (§3.14). It clears sex, height and birth year together, immediately, and the date of birth in §3.1 with them — the date is a figure you typed about yourself, so it goes with the rest of them. Nothing else in your record is touched. It is not a way back through the age check: the answer that check reached, and the moment it was taken, are untouched, and only the check itself moves the gate.
What you want to stopYour corrections being kept in our evaluation set	HowWithdraw the separate opt-in in Settings, or ask us (§12.5). We stop using them that way from then on; your own priors, and everything else about the service, are unaffected.
What you want to stopNutrient-floors mode being on	HowTurn it off in Settings. The floors computation stops, and the clinician-advised protein-limit setting is cleared with it (§3.5).
What you want to stopA mood tag or note on a meal	HowClear it on that meal.
What you want to stopA remembered fact	HowDelete it on the “What Eira knows about you” screen.
What you want to stopA single meal, weight or water entry	HowDelete it in the app.
What you want to stopEverything	HowDelete your account (§12.1).

Withdrawing consent stops future processing. It does not make unlawful the processing that happened lawfully before you withdrew.

6. AI processing

This is the section that deserves the most plain language, so it gets it.

6.1 What is sent, and when

Feature	What leaves our servers	To whom
FeaturePhoto meal logging	What leaves our serversThe downscaled, metadata-stripped meal photo	To whomAI vision provider
FeatureLabel and barcode teaching	What leaves our serversThe label photo, for text recognition	To whomAI vision provider
FeatureVoice logging	What leaves our serversThe text transcript only — never audio (§7.3)	To whomAI provider
FeatureDaily coaching message	What leaves our serversA compact context block carrying no name, no email address and no account identifier: your profile summary, recent trends and targets	To whomAI provider
FeatureCoaching chat	What leaves our serversYour message plus the same kind of context block	To whomAI provider
FeatureMemory extraction	What leaves our serversThe session text being extracted from	To whomAI provider
FeatureHistory questions	What leaves our serversYour question and a computed, grounded answer block	To whomAI provider
FeatureSemantic search	What leaves our serversThe text being embedded	To whomEmbeddings provider

Your name, email and account identifier are never sent. Prompts refer to you as “the user”. Context blocks carry only the fields a given task needs, never raw database rows.

6.2 Who processes it

All AI providers act as our processors — they process your data on our instructions and for no purpose of their own.

Provider	What it does for us
ProviderGoogle	What it does for usPhoto and label vision, coaching, daily messages, narrative summaries and memory extraction
ProviderOpenAI	What it does for usEmbeddings for semantic memory; a fallback for every task if Google is unavailable; and the primary model for a safety-escalation reply — the one turn we deliberately route elsewhere

No other AI provider receives your data. A fallback is triggered only by a transport failure, timeout, rate limit, server error, repeated schema failure or an open circuit breaker — never by what you said, and never by a low-confidence result. Every call records which provider actually served it, and a provider is never switched on before its data-processing agreement is signed and its configuration verified.

6.3 Training and retention

We do not send your data to an AI provider as training material. Not your record, not your photographs, not your corrections, not your chat. Nothing in the product does this, and §6.5 says what we do with corrections instead.

Our instructions to every AI processor forbid it any purpose of its own, and training on what we send it would be a purpose of its own. That instruction is what §6.2 describes and what the consent step names.

What we do not yet claim, and why we would rather say so. An instruction we give is not the same thing as a term a provider has signed up to, and we are not going to let the two blur together on a page about your health data. Until each AI processor’s data-processing agreement is executed and verified, this policy does not tell you that its terms prohibit training or cap retention — even where a provider’s published API terms say as much. No processor receives health data before that agreement is signed and its configuration verified (§6.2), and when they are in place we will state it here plainly and date the change under §17.

6.4 Observability of AI calls

We record traces of AI requests to diagnose failures and control cost, in an EU-hosted tracing service. A trace records what a call cost, not what it said: the model, the name of the prompt, token counts, latency and cost. No prompt or response text reaches the tracing service, the prompts themselves carry no identifiers, and photos are never sent to it.

6.5 Learning from your corrections

When you correct an estimate, we keep the before-and-after. It is used two ways: to build your own priors, so Eira gets better at your food specifically, and as our internal evaluation set, so a prompt or model change can be tested before it ships.

This is our own improvement loop, and it stays inside it. Corrections are not sent to any AI provider as training data — they are used by us, on our own infrastructure, to test a change before it ships (and see §6.3 for what we do and do not claim about the providers’ own terms). The distinction matters and we state it plainly rather than hiding behind “we may use your data to improve our services”.

The two uses are not the same kind of thing, so they are not consented to together. Your own priors are part of the product: they make your next estimate better, and they follow the same consent as the rest of your record. The evaluation set makes our next release safer, which is our benefit — so it is a separate opt-in you can decline at the start or withdraw later (§5.1, §5.2), and nothing about Eira changes if you do.

6.6 The estimate is an estimate

The AI identifies foods and portions. It never produces the calorie or macronutrient numbers — those are looked up in nutrition databases and computed arithmetically. Where the model’s own estimate diverges sharply from the database, confidence is lowered and Eira asks you rather than guessing.

The same discipline governs coaching: targets, floors and bands are computed deterministically in code; a model may restate a figure it was given, never originate one. Every user-facing AI output passes a safety filter before it reaches you.

6.7 We never use your data to advertise

Nothing in this pipeline feeds advertising, ad targeting, look-alike audiences or profiling for any third party. There is no advertising SDK in the app.

7. Apple Health and device data

7.1 What Eira reads and writes

Eira asks for Health permissions one feature at a time, at the moment that feature is first used.

Eira reads: body mass (weight) and dietary water; and, if you connect the activity-and-sleep feature, your step count, Apple exercise minutes, stand hours, sleep, and your finished workouts (including their walking/running, cycling and swimming distances). It does not read active or basal energy burned.
Eira writes: dietary water, dietary energy, protein, carbohydrates, total fat and fibre.

That is the whole scope, and each read is requested per feature, at the moment you first use it. If we ever add a type, this section and the App Store privacy label are updated in the same release.

7.2 The rules that ride with Health data

Data read from Apple Health, and data derived from it:

is used only to run features you asked for;
is never used for advertising or marketing;
is never sold, and is never disclosed to a data broker;
is never used for use-based data mining;
is never sent to any analytics SDK, and never written to a log line;
is never stored in our iCloud containers — Eira uses no CloudKit for health data at all.

You can revoke any Health permission in Apple’s Health app at any time. Eira keeps working with less to go on.

Only your iPhone writes to Apple Health. A meal logged on your Watch is sent to our backend and mirrored into Health by the phone, so nothing is double-counted.

7.3 Voice

Speech is transcribed on your device, with on-device recognition required. The audio recording never leaves your iPhone or Watch and is never uploaded to us or to anyone else. Only the resulting text transcript is sent to our server to be parsed into a food entry.

7.4 Photos

A meal photo is uploaded directly to our private storage under a key scoped to your account. Before anything else happens to it, our server:

verifies it really is an image, by inspecting the file’s bytes rather than trusting its name;
strips all metadata, including GPS coordinates — a meal photo’s location is health-adjacent location data, and there is no code path that keeps an unstripped photo past processing;
re-encodes and downscales it, and deletes the original.

Only the stripped, resized image is retained. Photos are served back to you through short-lived, per-request links; the storage bucket is fully private, with no public access and no listing.

7.5 Crisis resources and region

If you use coaching chat, your app may send a region hint so that the crisis and eating-disorder helplines shown to you are the ones in your country. That hint is never stored and never logged — it is used to render the block on that one reply and then discarded. If we cannot tell your region, you get the international resources instead; you are never shown nothing.

We do not sell your personal data. We do not share it for cross-context behavioural advertising. We show no ads. There are no advertising, marketing or data-broker recipients, and we have never had any. These are statements about the architecture, not aspirations: there is no advertising SDK, no analytics SDK and no marketing pixel anywhere in the app.

8.1 Sub-processors

We use a deliberately short list of processors. Each is here because a feature needs it, each is instructed to process your data for us and for no purpose of its own, and each is engaged under a data-processing agreement before it receives personal data.

The list is in two halves, because the app and the website are different systems with different processors, and running them together in one table is how a website processor ends up undisclosed.

The app and its backend:

Recipient	What it receives	Where
RecipientHetzner	What it receivesHosting for the application and the database — all primary data	WhereGermany
RecipientCloudflare R2	What it receivesMeal and label photos, export bundles, encrypted backups	WhereBucket jurisdiction set to the EU; US parent company
RecipientSupabase	What it receivesAuthentication only — your identity, no health data	WhereEU project
RecipientBackblaze B2	What it receivesA second, client-side-encrypted copy of backups	WhereEU region bucket
RecipientGoogle	What it receivesAI processing (§6)	WhereUS company
RecipientOpenAI	What it receivesAI processing and embeddings (§6)	WhereUS company
RecipientSentry	What it receivesScrubbed error events — no health data	WhereUS company
RecipientLangfuse	What it receivesMinimised AI traces — no photos, no identifiers	WhereEU region
RecipientApple	What it receivesPush notification delivery (a token, and a payload with no health content); App Store billing	WhereApple’s infrastructure
RecipientFatSecret, USDA FoodData Central, Open Food Facts	What it receivesA food name or a barcode. No account identifier, and nothing about you, is sent to a nutrition database.	WhereRespective providers

The website, eira.coach:

Recipient	What it receives	Where
RecipientCloudflare (hosting and the two form handlers)	What it receivesThe website itself, and everything you submit on it. As the host it terminates the encrypted connection, so it sees a form submission in the clear on the way to us, and it holds ordinary connection metadata for it: your IP address, your browser’s user-agent string, the page you came from, a request identifier, and the country it infers from the connection. Nothing from the app passes through it.	WhereUS company. Pages and form handlers run at the network location nearest you, which may be anywhere, including in the United States
RecipientResend	What it receivesContact-form messages, for delivery only: the name, email address and message you typed on /contact	WhereUS company (Delaware)
RecipientCloudflare Email Routing — the mail route behind hello@eira.coach	What it receivesEvery contact-form message after delivery, and any mail you send to that address yourself. It receives the message at our domain and forwards it to the mailbox below	WhereUS company
RecipientGoogle — the Gmail mailbox behind hello@eira.coach	What it receivesEvery message that reaches that address. This is where a message comes to rest, is read by a person, and is kept for the 24 months in §10	WhereUS company
RecipientBrevo	What it receivesThe early-access mailing list: name, email and the consent record (§3.13). No health data, and nothing from the app.	WhereEU company

Because §1.2, §12.5 and §18 all invite you to use the contact form for a privacy request, a complaint or a security report, the website rows above deserve to be read rather than skimmed: a message of that kind travels through them. If you would rather it did not, write to legal@eira.coach directly instead. That leaves out the form handler and the delivery provider; your own mail provider, our mail route and our mailbox are still in the path, as they are for any email anyone sends anyone.

8.2 Other disclosures

We may disclose personal data:

To comply with law — a valid court order, subpoena or regulatory demand. We will tell you unless we are legally prohibited from doing so.
To protect rights and safety — where necessary to investigate fraud, abuse or a threat to someone’s safety.
In a corporate transaction — if Eira is acquired or merged, your data may transfer to the acquirer. We will notify you before any such transfer, and your health data will remain subject to this policy or to one no less protective of you.

9. International transfers

Stated as compliance facts, plainly.

Your account, your record and your photos are hosted in the European Union — the application, database and object storage all sit in EU jurisdictions. Encrypted backups are held in the EU. That sentence is about the app and its backend, which is where your record lives; the website is the next bullet.
The website does not run in one place, and that is how a content-delivery network works. eira.coach and the two form handlers behind it are served from whichever of the host’s locations is nearest the person loading the page — which, for a great many readers, is in the United States. The host terminates the encrypted connection, so a form you submit is visible to it before it reaches us. A contact-form message is then handed to a US delivery provider and comes to rest in our mailbox; an early-access signup goes to Brevo. All of it is in §8.1.
Eira is offered in the United Kingdom and the United States. Wherever you use it from, your record is transferred to and stored on the infrastructure described above.
Some processing happens with US-based providers. In particular, the AI providers that analyse a photo or write a coaching reply, our error-reporting provider, and the website processors above are US corporations. For a user in the United Kingdom that is a restricted transfer under the UK GDPR, even where the service itself runs in a European region.
We are in Kosovo, and that is a transfer too. It would be odd to name every other country and not our own. Codes L.L.C. is established in the Republic of Kosovo, which is not covered by a UK adequacy regulation. Running the service — operating the database, answering a support message, investigating a fault — means that people here reach data held in Europe, and that access is itself a restricted transfer, even though nothing is copied out. Kosovo has its own data-protection law, Law No. 06/L-082, which is built on the GDPR and supervised by its own agency, so the domestic standard is not a gap. The transfer safeguard for this route is the UK International Data Transfer Agreement, or the UK Addendum to the Standard Contractual Clauses, and putting it in place with each provider that holds data for us is work we are completing before launch.
Every other such transfer runs under an approved safeguard — the UK International Data Transfer Agreement, the UK Addendum to the Standard Contractual Clauses, or the UK Extension to the EU–US Data Privacy Framework where the recipient is certified under it.

A copy of the safeguards we rely on is available on request — ask through the contact form.

10. How long we keep it

Data	Retention
DataYour record — food, water, weight, fasting, mood, memory, coaching	RetentionFor as long as your account exists. A companion with a memory is the product. You can delete any individual item at any time.
DataThe date of birth you gave at the age check (§3.1)	RetentionFor as long as your account exists, and deleted with it. The age check itself is taken once: the verdict is recorded at your first submission and cannot be re-taken, whether or not the date it was drawn from later changes.
DataRaw, unprocessed photo uploads	RetentionDeleted immediately after processing, with a storage lifecycle rule removing any remainder within 24 hours
DataProcessed meal photos	RetentionWhile the meal exists; deleted when you delete the meal or the account
DataAI request traces	Retention90 days
DataError events	Retention90 days
DataEncrypted backups	RetentionRotated daily for 7 days, weekly for 4 weeks, monthly for 6 months — so a deleted account can persist in an encrypted backup for up to about six months
DataDeleted-account marker	RetentionAn account identifier and a deletion timestamp only — no personal data — kept indefinitely, so that a restored backup can be re-deleted and a deleted identity cannot be silently re-created
DataProducts you taught Eira	RetentionKept in the shared catalogue, unlinked from you — see §3.12
DataMessages you send through the contact form	Retention24 months, then deleted
DataYour early-access list entry	RetentionUntil you unsubscribe or ask us to remove it, and then deleted — and in any case no more than 24 months after you joined. A list is for telling you about a launch; if we have not managed that in two years, we would rather ask you again than keep an address that has been sitting there.

10.1 What happens when you delete your account

Your record is erased from the live database in a single cascading delete — every table, including the semantic embeddings, by hard delete, never a soft flag.
Your photos, label images and export bundles are deleted from object storage.
Your identity is deleted at the authentication provider, which removes every linked sign-in.
Your push tokens are purged.
The job ends by counting the remaining rows and storage objects for your account and asserting the answer is zero — the deletion is verified, not assumed.
The semantic index is rebuilt, because a vector index can retain traces of a deleted entry in its internal structure. The rebuild is enqueued in the same transaction that deletes your record, and a weekly rebuild runs behind it as a backstop in case that one does not complete. Your embeddings are therefore provably gone from the index within 7 days of deletion.
Backups are handled as set out in the table above.

11. Security

Security is treated as product spend here, not overhead, because the product’s premise is trust.

11.1 Access and isolation

Encryption in transit (HTTPS only, with HSTS) and at rest.
Exactly one authorisation rule: you can access only your own rows. Your account identifier comes only from your verified session token — never from a URL, a query parameter or a request body — and every query on your data is filtered by it. Asking for someone else’s record returns “not found”, indistinguishable from a record that does not exist. This is enforced by a test suite that, for every endpoint, asserts one user cannot reach another’s data.
Object identifiers are non-sequential and non-enumerable.
Access tokens are short-lived (one hour) with rotating refresh tokens and replay detection. Tokens are stored in the iOS Keychain, device-only, never in plain preferences.
The database is never exposed to the public internet. Administrative access is direct and logged; there is no admin API surface.

11.2 Data-minimisation controls

GPS and all other metadata stripped from every photo before storage (§7.4).
Uploads validated by file content, size-capped, and written only under your own account’s key prefix.
Rate limits on every endpoint, tighter on AI-invoking and authentication-adjacent ones.

11.3 Health data is excluded from logs and analytics by design

This is the rule the rest of the architecture is built around:

No health value is written to a log line. Body measurements, medication data and mood notes are explicitly excluded. The safety check in §3.3 writes no verdict and no identifier either: what it emits is the context-free count described there, which names nobody and says nothing about what was read.
No health data reaches an analytics SDK, an advertising network, or a data-mining process. There is currently no product-analytics SDK in the app at all (§14).
Error reports are scrubbed before they leave the server, including stripping local variables from failing code frames.
Push notification payloads carry static text and identifiers only.
No health data is stored in any iCloud container.

11.4 Backups

Backups are encrypted before they leave our infrastructure, held in two EU locations, and restore-tested rather than assumed.

11.5 Honest limits

No system is perfect, and we would rather say so than imply otherwise.

What is in place is what §11.1 to §11.4 describe, and none of it is aspirational: one authorisation rule, tested endpoint by endpoint; short-lived tokens with rotation and replay detection; a database never exposed to the public internet and no admin API surface; metadata stripped from every photo before it is stored; rate limits on every endpoint; health values kept out of log lines by construction rather than by review; and backups encrypted before they leave our infrastructure, held in two places and restore-tested rather than assumed.

What is not yet in place, we know about. We are a small team, and there is security work we have assessed and not yet done. It is written down internally — each item with the reason it is open and what would close it — and reviewed rather than left to drift. We do not publish that list, because a public description of what a system does not have is most useful to the people we are defending against; we will share it under a confidentiality agreement with a partner, an insurer or a business customer who needs it.

If a breach affects your data, §16 says what we will do.

12. Your rights

We never charge for a rights request, never require you to create anything extra to make one, and never treat you differently for exercising one.

12.1 Rights you can exercise inside the app, right now

Right	Where
RightAccess and portability — a complete, machine-readable copy of your record	WhereSettings → export. It is generated as structured JSON covering your profile — including the date of birth you gave at the age check (§3.1) — every food log and item, your meal and label photographs, weights, water, water presets, recipes, fasting sessions and the acknowledgement you gave before the first one (§3.7), your mood tags and your free-text mood note (§3.3), whether nutrient-floors mode is on, and the clinician-advised protein-limit setting (`protein_limit_advised`) if you set one (§3.5), corrections, calorie targets and dismissals, extracted facts, coaching sessions and messages, profile summaries, daily messages, devices and subscriptions.
RightRectification — correct anything wrong	WhereEdit any meal, item, portion, weight or remembered fact in the app. Corrections take effect immediately, and coaching follows them. The date of birth in §3.1 can be corrected in the app too (§3.4, §5.2). What no correction does is re-take the age check, which is submitted once — if that check went against you, §15.1 is the route.
RightErasure — of one item or of everything	WhereDelete a meal, a weight, a water entry, a remembered fact, a mood tag, or your whole account. Account deletion is in-app, confirmed, and runs the cascade in §10.1.
RightWithdraw consent to hold your body measurements	WhereSettings → About you → “Remove your biometric data” — the button’s label; what it clears is sex, height and year of birth (§3.4, §3.14), and the date of birth in §3.1 with them (§5.2)
RightRestrict Apple Health access	WhereApple’s Health app

How the export reaches you. It is produced in the app and handed to you there, as a file you save or share wherever you like. It is not emailed, and there is no link to wait for. If your record is large enough that the app cannot produce it in one pass, write to us (§12.5) and we will get it to you another way rather than leave you with a spinner.

If you are in the United Kingdom you have the rights to access, rectification, erasure, restriction of processing, data portability, objection (including to processing based on legitimate interests), and to withdraw consent at any time without affecting the lawfulness of processing before withdrawal. Where the law of another country gives you equivalent rights, they apply there too — §12.1 is how most of them are exercised, and it is open to everyone.

You also have the right to lodge a complaint with a supervisory authority in the country where you live, work, or where you believe an infringement occurred. In the UK that is the Information Commissioner’s Office, which is competent to deal with us. We would much rather you gave us the chance to put it right first, but that is your choice, not a condition.

We respond within one month, extendable by two further months for complex requests, and we will tell you if we need the extension.

12.3 California — CCPA/CPRA rights

Health information collected by a wellness app like Eira is not covered by HIPAA, so it falls squarely within the CCPA/CPRA. As a California resident you have the right to:

Know what personal information we collect, use and disclose — §3 is that disclosure, by category and by source.
Delete your personal information — §12.1.
Correct inaccurate personal information — §12.1.
Opt out of sale or sharing. We do not sell your personal information and we do not share it for cross-context behavioural advertising, so there is nothing to opt out of and no “Do Not Sell or Share” link is required. We have not sold or shared personal information in the preceding 12 months.
Limit the use and disclosure of sensitive personal information. Your health data is sensitive personal information. We already use it only for the purposes you asked for — providing the service you requested — and never to infer characteristics about you for any third party, so the right is satisfied by our default behaviour rather than by a toggle.
Non-discrimination for exercising any of these.

California’s second health law — the CMIA. The CCPA is not the whole of it. California’s Confidentiality of Medical Information Act was written for hospitals and insurers, but Cal. Civ. Code §56.06(b) now also treats a business offering a mobile application designed to hold medical information as a provider of health care for the Act’s purposes — which is a description of Eira, so we work on the basis that the Act applies to us. In practice that means: your health information is not disclosed without your authorisation except where the Act itself permits it; it is not used for marketing; and §11 describes the safeguards kept around it, which §56.101 requires to be reasonable rather than merely stated. The Act also gives you a right to sue directly, and damages under it do not depend on showing you were harmed. We would rather tell you that plainly than let you discover it from someone else.

Neither the CCPA analysis above nor this paragraph is legal advice about your own position, and neither is a claim that a regulator or a court has approved how we do any of it.

12.4 Other US states

If you live in a state with a comprehensive privacy law — Virginia, Colorado, Connecticut and the growing list that follows their model — you have equivalent rights to access, correct, delete and obtain a portable copy, and to opt out of targeted advertising, sale, and profiling with legal or similarly significant effects. We do none of those three, so there is nothing to opt out of.

These laws treat health data as sensitive data requiring opt-in consent before processing, which is consistent with the explicit-consent basis in §5.

You may appeal a refused request; if we refuse an appeal, you may complain to your state Attorney General.

Washington and Nevada are separate. Both have a consumer-health-data law of their own, with its own definitions and its own rights — including a right to have consumer health data deleted within 30 days. Those laws require a policy that stands on its own rather than a paragraph inside this one, so they have it: Consumer Health Data.

12.5 How to exercise a right we cannot handle in-app

The ordinary route is the app, signed in. Export, correction and deletion are all there (§12.1), and being signed in is the strongest proof of identity there is — it is the same proof that opens your record in the first place.

But you never need an account, or access to one, to ask us for something. Write to legal@eira.coach or use the contact form; a person reads both. We will not ask you to create an account, to sign in, or to install anything in order to make a request, and we will not send you round in a circle if the thing you cannot do is sign in.

We may need to be satisfied that a request really comes from the person it concerns — but we ask for that only where there is a genuine doubt, and never as a way of making the right harder to use. What we ask for depends on what you are asking us to do:

If you can sign in, the simplest thing is to make the request in the app. By email, tell us something from your own record that only you would know. Note that writing from the address on the account does not by itself identify it: if you used Apple’s Hide My Email, that address is a relay we cannot search on (§3.1), so we ask for something else instead of pretending the email is a key.
If you cannot sign in — a lost Apple Account, or an account stopped at the age check (§15.1) — say so, and give us what you have: the Apple Account you signed in with, an address any Eira mail reached you at, roughly when you created the account, and anything else that fits. We work with what you can show us rather than insisting on one particular proof, and a person, not a form, decides.
If you are acting for someone else — under a power of attorney, as a parent, or as the representative of someone who has died — tell us the basis you are acting on and we will tell you what we need to see. We will not use that step to avoid answering.

We answer within the times in §12.2, we never charge for a request, we never treat you differently for making one, and we will not ask you to justify why.

13. Children

Eira is for adults. You must be at least 18 years old to create an account. A version for teenagers would be a different product, with paediatric references and parental consent, rather than a setting.

We do not knowingly collect personal data from anyone under 18. If we learn that we have, we delete the account and its data. If you believe a child has given us data, tell us through the contact form and we will act on it.

We do not knowingly sell or share the personal information of anyone under 16, and we have no mechanism by which we could.

14. Cookies, tracking and analytics

14.1 In the app

There is no advertising SDK, no attribution SDK, no advertising identifier, no tracking pixel and no cross-app or cross-site tracking. Eira does not present an App Tracking Transparency prompt, because it does not track you.

There is currently no product-analytics SDK in the app either. The only diagnostic collection is the scrubbed error reporting described in §3.11 and §11.3. If that ever changes, this section and the App Store privacy label change with it, in the same release.

14.2 On the website

The website sets no cookies, runs no analytics, and loads nothing from a third party — no font service, no embedded video, no tag manager. There is no consent banner because there is nothing to consent to. Fonts, images and the small amount of code the page runs are all served from eira.coach itself.

Two things leave this site: the contact form, and the early-access form in §3.13. Both post to eira.coach rather than to somebody else’s server — but that is a fact about your browser, not about your data. The site is hosted on a content-delivery network, so the code that receives your submission runs on that network’s infrastructure and the host sees what you typed before we do. A contact-form message is then handed to an email provider for delivery and stored in our mailbox; an early-access signup is written to Brevo. Those processors are named in §8.1 with what each one gets, and §9 says where they are. We would rather say this than let “same domain” do work it cannot do.

15. Automated decision-making and profiling

Eira profiles you in the ordinary sense — it learns your habits and patterns, because that is the product.

One automated decision in Eira does have a significant effect on you: the age check. It is solely automated, it decides whether you may use the Service at all, and it gets its own section below rather than a footnote. Everything else Eira works out about you is proposed to you and takes effect only if you accept it.

Concretely, and this is a design rule rather than a policy assertion:

A calorie target is proposed and never applied. Eira estimates and suggests; the number your app actually uses moves only when you press accept. Merely viewing a proposal writes nothing at all. This deliberately replaced an earlier design in which a weekly job adjusted the target automatically, on the reasoning that an auto-decreasing calorie target is the mechanic of a restrictive diet.
The memory asks rather than assumes. A contradiction touching an allergy or a medical fact is never resolved automatically — Eira asks you.
Safety routing can change which model answers a coaching message, and can substitute a safe reply carrying crisis resources. That affects the text you receive; it makes no decision about you, grants or withholds nothing, and is subject to human oversight by us.
The safety check on your own words (§3.3, consented to under §5.1) is automated, and we say so here rather than let you find it. What it can do is add support lines under a saved meal and, in chat, route the reply as above. What it cannot do is anything else: it stores no verdict, writes nothing to your record, tells nobody, and cannot refuse, delay or alter a single thing you log. It produces no decision about you within the meaning of Art. 22 — but the honest way to make that claim is to describe the check, so that is what §3.3 does.

Nothing here profiles you for advertising, credit, insurance, employment or any third party.

15.1 The age check, which is an automated decision

Eira is for adults (§13). When you first open it you give your date of birth (§3.1), and a check on our server — not a person — decides from that date whether you may use the Service. It is made solely by automated means, it denies access entirely rather than partly, and the check is write-once — a second submission is refused — so you cannot simply answer it again. Changing the date afterwards does not re-open it: only the age check moves the gate, and it has already been taken. That is an automated decision with a significant effect on you, and it is easier to say so than to argue it is not.

Why it is built that way. An adults-only rule a person could talk their way past would not be a rule. The lawful basis is Art. 22(2)(a) — the decision is necessary in order to enter into a contract with you, because there is no version of this contract we can enter into with someone under 18.

What you can do about it. Art. 22(3) gives you three things, and none of them requires you to get past the block first:

A human will look at it. Write to legal@eira.coach, or use the contact form — from any address, on any device, without being signed in. A person reads it, and a person decides.
You can put your side of it. Tell us what happened. A mistyped year is the ordinary case, and it is the case we expect.
You can contest the outcome. Correcting the date in the app does not move the gate on its own — the check does not re-run — which is exactly why this route exists and why a person, not the server, decides it. If you are under 18, we cannot let you in — we will tell you so plainly rather than leave you guessing — and you can still ask us for a copy of what we hold about you and to erase it, through the route in §12.5.

16. Data breaches

If a personal-data breach occurs we will:

notify the competent supervisory authority within 72 hours of becoming aware of it where that is feasible, where the breach is likely to result in a risk to your rights and freedoms (GDPR Art. 33) — and where it is not feasible in 72 hours, notify it as soon as it is and say why it took longer, which is what Art. 33 itself requires;
notify you without undue delay where the breach is likely to result in a high risk to you (GDPR Art. 34). Because Eira holds health data, we will assume a breach of your record is high-risk unless there is a clear reason to conclude otherwise;
comply with applicable US state breach-notification laws, which may impose their own timelines and content requirements; and
tell you what actually happened, not a sanitised version of it.

Our incident procedure — containment, credential rotation, forensic snapshot, notification templates and authority contacts — is written down in advance rather than improvised during an incident.

17. Changes to this policy

If we change how we handle your data in a way that matters, we will tell you in the app before the change takes effect. If you are on the early-access mailing list and have no app to be told in, the same notice reaches you by email, at the address you gave us — a change you cannot hear about is not a notice. Where a change requires your consent — in particular any new purpose for health data, or any new AI processor — we will ask for it rather than assume it.

Every version of this policy carries a version number and an effective date, shown together at the top of the page, so you can tell which one you are reading and when it started to apply. We keep previous versions available on request at legal@eira.coach: quote the version number of the one you want.

What changed in each version, most recent first:

1.5 — 23 August 2026, §3.1, §3.4, §10, §12.1 and §15.1. Corrected what these sections said about the date of birth you give at the age check. Version 1.4 said it could not be edited in the app and that a correction had to be asked for; it can be edited, and asking us was never the only route. What is taken once is the age check — a second submission is refused — and that is what §15.1’s automated-decision analysis now rests on. What changed in this version is the description. The behaviour it describes is the behaviour that was already running, and no processing of your data changed with it.
1.5 — 23 August 2026, §3.1, §3.4, §3.14, §5.2 and §12.1. Corrected what “Remove your biometric data” clears. Version 1.4 said in three places that it cleared sex, height and year of birth only, and in two of them that the date of birth in §3.1 survived it. It does not: the date is cleared with them. The verdict of the age check, and the moment it was taken, are untouched, so the withdrawal does not reopen the age question — which is what those passages were for and is why it is still said. Again a correction to the description, not a change in what the button does.
1.5 — 23 August 2026, §10.1. Corrected the rebuild of the semantic index after an account deletion. Version 1.4 described a monthly schedule and a ceiling of 31 days; the rebuild is enqueued in the same transaction that deletes the record, with a weekly rebuild behind it, so the ceiling is 7 days. This is a correction to the description, not a change to what happens when you delete your account.
1.4 — 18 August 2026, §6.4. Corrected what the tracing service receives: the model, the prompt name, token counts, latency and cost, and no prompt or response text at all. Version 1.3 also described an automatic mask over email- and phone-shaped strings; there was no such mask, and with no text sent there is nothing for one to do.
1.4 — 18 August 2026, §7.1. Removed resting heart rate from what Eira reads from Apple Health. The app no longer requests it, so version 1.3 disclosed a read that does not happen.

18. Contact and complaints

Controller: Codes L.L.C., Kodra e Diellit, H 1/2, Nr. 22, Prishtinë, Republic of Kosovo, company number 810858003

Privacy contact: the contact form, or legal@eira.coach

Supervisory authority: in the United Kingdom, the Information Commissioner’s Office. Elsewhere, write to the authority in your own country, which is competent to deal with us (§12.2).

Consumer health data (Washington and Nevada): the separate policy at Consumer Health Data, and the same addresses above.

Security reports: legal@eira.coach

United Kingdom: you may lodge a complaint with the Information Commissioner’s Office.

California: you may contact the California Privacy Protection Agency or the California Attorney General.

Other US states: you may contact your state Attorney General.