bGuru Privacy Policy

Last updated: 2026-08-27

§0 Plain-language summary

bGuru is a free social network for sports predictions. To run it, we collect a small amount of personal data about you: your email and display name, the picks you make, the groups you join, and (if you opt in) a push notification token. That's most of it.

We do not sell your data. At this version of the Service (MVP), we do not show ads. The AdMob advertising SDK was removed from the MVP build on 2026-06-08. A future version (v1.1+) may introduce non-personalized contextual advertising via Google AdMob; if and when that happens, we will notify you 30 days in advance via the §11 material-change notice flow, and we will update this Policy before any ads serve. We do not read your Apple IDFA or Android Advertising ID. We do not build a behavioral profile of you for advertising. We will never show profiling-based or interest-based ads to users under 18 at any version of the Service. We do not track you across other apps or websites.

bGuru does not allow gambling, sports-betting, sportsbook, casino, odds-provider, or betting-affiliate advertising. This policy applies to any future advertising and is an absolute limit at every version of the Service.

The two third parties who actually see your data are Supabase (our database provider in Frankfurt) and OneSignal (the push notification service). We also use Sentry (in the EU) to find out when the app crashes — Sentry never receives your email, your display name, your account ID, or any other identifier, so we cannot tell from a crash report which specific user it came from.

You can ask to see, correct, export, or delete your data at any time — through Settings or by emailing legal@bguru.app. We'll respond within one month, faster on urgent matters.

You must be at least 16 to use bGuru. If we find out a user is under 16, we delete the account immediately.

The rest of this Policy is the detail behind the headlines.

§1 Definitions

Terms used in both this Privacy Policy and the Terms of Service have the same meaning as in the Terms of Service (see Terms of Service, §1 Definitions). The following Privacy-Policy-specific terms apply:

• Personal Data — any information that identifies you, or that can identify you when combined with other information we hold. The exact statutory definition varies by jurisdiction; see §3.2.
• Special Category Data — heightened-protection categories under GDPR Art. 9 and equivalent regimes (e.g., health, biometric, racial origin, religious belief). bGuru does not collect Special Category Data.
• Processing — anything we do with Personal Data: collect, store, organise, alter, retrieve, disclose, erase, etc.
• Sub-processor — a third party that processes Personal Data on bGuru's behalf. See the sub-processor list.
• Controller — the entity that decides why and how Personal Data is processed. For bGuru, that's the entity identified in §2.
• Data Subject — you, the person the Personal Data is about.

§2 Who we are (controller identity)

The controller of personal data processed through the Service is:

bGuru (operating as a sole-proprietorship project of an Israeli resident) Web: bguru.app Jurisdiction: Israel Contact: legal@bguru.app

Formal entity formation (Israeli Ltd. or Estonian OÜ) is pending post-MVP review. This section will be updated via the standard 30-day material-change notice mechanism (see Terms of Service, §16) once the entity decision is finalised.

For data-protection purposes:

• EU/EEA Art. 27 representative — appointment deferred. In the interim, legal@bguru.app is the direct contact channel for EU/EEA users and supervisory authorities; we commit to responding within one month per GDPR Art. 12(3).
• UK Art. 27 representative — same posture; appointment deferred; legal@bguru.app is the interim channel for UK users and the ICO.
• Data Protection Officer (DPO) — not appointed at MVP. The processing profile at MVP (no large-scale processing of special-category data, no large-scale systematic monitoring of individuals) does not trigger mandatory DPO appointment under GDPR Art. 37(1)(b) or (c). For Israeli law: bGuru is currently below the PPL Amendment 13 database-registration thresholds (10,000 Israeli residents / 100,000 individuals worldwide holding sensitive information); we monitor user-count growth against these thresholds and will register the database with the PPA and appoint a DPO promptly upon crossing either threshold.

§3 Data we collect

§3.1 Data we actually collect at this version of the Service

Account data (required to use the Service):

• Email address — used as your login identifier; not displayed publicly.
• Display name — your public handle on bGuru, set during onboarding (unique, URL-safe).
• Hashed credential or OAuth token — the password is hashed (bcrypt via Supabase Auth) and is never visible to bGuru; OAuth (Google, Apple, Facebook) returns only a stable identifier.
• Profile fields — bio (optional).
• Location — not collected at this version of the Service. bGuru does not detect or estimate where you are, from your connection or from your device. A future version will let you share your device's location, once, only if you choose to and allow it in your phone's own permission prompt, to show your standings among nearby predictors — and we will update this section, in the same release, before that ships.
• Avatar image (optional) — either uploaded by you directly, or imported once from your social-login provider's profile picture at signup (Google or Facebook). If you sign in with Google or Facebook, we fetch your profile picture from that provider once at signup and store it on our own servers in the Frankfurt region (Supabase Storage, EU). We do not continuously read your profile picture from your social account — after the one-time import you can change or remove your avatar in bGuru independently of your social-login account. Avatars are deleted when you delete your account. Storage provider: Supabase (Frankfurt); see §5 and the sub-processor list.

Prediction and social data (the core service):

• Picks (predictions) — each Pick records: market identifier, outcome chosen, conviction context, timestamp, and the user who submitted it.
• Conviction scores — computed at lockout (5 minutes before kickoff) based on diversity/unanimity of your Picks across contexts.
• Group memberships, follows, comments, reactions, group descriptions.
• Reputation points + leaderboard positions — derived, recomputed periodically; not free text.

Push notification data (only if you opt in):

• OneSignal player_id — a unique identifier issued by OneSignal for your device.
• Push token — issued by Apple APNs or Google FCM, stored only as long as needed to deliver notifications.
• Notification preferences (opt-in/opt-out, topic subscriptions).

Crash + performance data (Sentry, EU region):

• Device model, operating-system version, app version.
• No user identifier of any kind is sent to Sentry — not your email, not your display name, not your account ID, and not a device ID. bGuru's Sentry integration never calls Sentry's user-identification API, and the Sentry SDK does not generate one of its own, so nothing else takes its place. Your IP address is not sent to Sentry either (Sentry's IP-address inference is disabled at the SDK level).
• Error stack traces, network-request metadata (URL only, no body), performance metrics.

Connection data (transient):

• IP address — held in memory for rate-limiting + breach-detection (typically <24 hours); not stored long-term.
• Session JWT — used to authenticate your requests; rotates on sign-out.

Account-deletion data:

• Deletion-requested timestamp + 30-day grace-period state.

Product analytics data (first-party, in-house — no third-party analytics SDK):

• Per-event data — event name (e.g., screen viewed, prediction submitted), screen name, timestamp, a per-app-launch session identifier, platform (iOS/Android), app version + build number, and small structured context relevant to the event (e.g., which fixture or group an action touched).
• Server-derived session events — sign-in / app-activity markers, generated from our own authentication system's token activity rather than a separate SDK. Collected since 2026-07-19, with history reconstructed back to launch (2026-06-08).
• All product analytics data is linked to your account (user ID). We do not use a third-party analytics vendor — no Firebase/Google Analytics, no Mixpanel, no PostHog, no Amplitude, or any similar service. This data is collected and stored exclusively in our own database in the Frankfurt (EU) region and never leaves it. Internal test accounts are excluded from analytics, and development builds do not send analytics events.
• Purpose: to understand feature usage and app stability so we can operate and improve the Service. This data is never used for advertising, profiling, or marketing, and is never shared with any third party.
• Deleted automatically and atomically when you delete your account, via the same database cascade described in Terms of Service, §10 Account deletion. See §7 for the retention period that applies while your account is active.

We do NOT collect:

• Special Category Data (GDPR Art. 9).
• Financial data (no payment flow at MVP).
• Location of any kind, from your connection or from your device — see "Location" above.
• Apple IDFA or Google Advertising ID — bGuru does not request, collect, or pass IDFA or GAID to any ad network at this version of the Service. If we ever introduce features that require IDFA access, we will surface an ATT prompt before any read.
• Ad-impression data — no advertising SDK is active at MVP; no ad data is transmitted to Google AdMob or any other ad network.
• Behavioral-tracking data for advertising, marketing, or profiling purposes. We do not build an interest graph or an advertising profile of you, and no cross-app or cross-site tracking occurs. (This is distinct from the first-party product analytics described above, which we collect solely to operate and improve the Service — never for advertising or marketing, and never shared with anyone.)

§3.2 Jurisdiction-specific data definitions

Israel (PPL 5741-1981 + Amendment 13). Under the Privacy Protection Law 5741-1981 / חוק הגנת הפרטיות, תשמ"א-1981 as materially modernised by Amendment 13 (enacted 2024, effective August 2025), "personal information" (מידע אישי) means any information that identifies or can identify a natural person, or information about the personality, personal history, intimate life, health condition, economic situation, opinions, and beliefs of a specific person. This broadly tracks GDPR Art. 4(1), with one substantive Israeli-law difference: the PPL treats financial information (economic situation, income, assets, indebtedness) and information about personal beliefs and opinions as categorically sensitive by default. Under GDPR Art. 9, financial information is not a "special category"; under the PPL, it is. The practical consequence for bGuru at MVP is limited — bGuru does not collect financial information — but the classification matters for future paid tiers. Amendment 13 also introduced a separate "sensitive information" tier — retitled "highly sensitive information" (מידע רגיש במיוחד) by the Amendment itself — that aligns with GDPR Art. 9 (health, biometric, sexual orientation, religious and political affiliation, racial or ethnic origin, criminal history) and imposes stricter processing obligations and a duty to report to the PPA within 30 days where a controller not otherwise subject to registration holds it on more than 100,000 individuals. bGuru does not collect health, biometric, genetic, sexual-orientation, religious/political-belief, racial-origin, or criminal-history information at MVP. Several English-language compliance summaries of Amendment 13 describe this tier as extending further, to cover location and traffic data. This version of the Service does not collect location at all (see §3.1), so this question does not currently apply to bGuru. A future, optional device-location feature (see §3.1) would revisit this question, and would in any case run on explicit consent rather than on any of the other grounds in §4, before it ships. Full analysis: docs/legal/_research/decisions-log.md, "User location — all collection removed; GPS-only opt-in deferred to local standings (2026-08-27)." Advertising posture (Israel): At this version of the Service, bGuru does not run advertising. No ad SDK is active; no IDFA or GAID is requested or passed to any ad network. Communications Law §30A opt-in for marketing communications is not triggered (§30A applies to direct electronic marketing communications addressed to the individual; it does not apply to contextual display advertising, and there is no display advertising at MVP). If a future version introduces advertising (planned for v1.1+), bGuru will reassess the PPL legitimate-purpose analysis and will issue a 30-day material-change notice before any ad serves.

Provisions for other regions are set out in Appendix A — Region-specific provisions, §3.2, at the end of this policy.

§4 Why we collect it (lawful basis)

§4.1 Lawful bases overview

Each category of data we collect from §3.1 is processed under a specific lawful basis. The same mapping applies in substance across all jurisdictions, with jurisdiction-specific terminology in §4.2.

Data category (from §3.1)	Lawful basis	Why
Account data (email, display name, password hash, OAuth token, profile fields including bio)	Contract performance	We can't provide the Service without it
Location	Not applicable — not collected at this version	Not collected at all, from your connection or your device — see §3.1. A future, optional device-location feature would run on Consent, and this row will be updated before it ships.
Avatar image (user-uploaded or imported once from OAuth provider at signup)	Contract performance	Rendering an account identity surface in the app requires an avatar slot; the processing is necessary to perform the contract
Prediction + social data (Picks, conviction, groups, follows, comments)	Contract performance	This IS the Service
Push notification data (OneSignal player_id, push token, preferences)	Consent	Explicit opt-in via system permission prompt + soft-prompt logic
Crash + performance data (Sentry)	Legitimate interest	Service stability + security; minimal data; balancing test applied (see §4.2)
Connection data (IP, session JWT)	Legitimate interest	Necessary for rate-limiting + security; transient
Product analytics data (event name, screen name, timestamp, session id, platform, app version, structured context)	Legitimate interest	Understand feature usage and app stability to operate and improve the Service; minimal, first-party only, non-marketing, no third-party sharing; balancing test applied (see §4.2)
Ad-impression data	Not applicable at MVP	No advertising SDK is active at this version of the Service. When advertising is re-introduced in v1.1+, this row will be updated with the applicable lawful basis and balancing-test analysis before any ad serves.
Account-deletion data (timestamps, grace-period flag)	Legal obligation	Demonstrates compliance with statutory erasure rights

We do not rely on vital interests (GDPR Art. 6(1)(d)) or public task (Art. 6(1)(e)) for any processing.

§4.2 Jurisdiction-specific lawful bases

Israel (PPL Amendment 13). The PPL operates through a functionally equivalent framework: processing is lawful if (a) done with the data subject's consent (הסכמה) — the PPL's primary and default ground; (b) required for performance of a legal obligation (חובה חוקית); (c) necessary to perform a contract; or (d) serves a legitimate purpose (מטרה לגיטימית) that does not disproportionately infringe privacy (a ground Amendment 13 codified more explicitly, bringing it closer to GDPR Art. 6(1)(f)). Mapped to bGuru: account + predictions + groups + social = contract performance; Sentry crash data and first-party product analytics data = legitimate purpose with data minimisation — both are minimal, first-party only, never used for advertising or marketing, never shared with any third party, and deleted automatically on account deletion; push notifications = explicit consent. This version of the Service does not collect location (see §3.1); a future, optional device-location feature would run on explicit consent, and this paragraph will be updated before it ships. No advertising processing at this version — advertising is deferred to v1.1+; when re-introduced, the PPL legitimate-purpose analysis will be added here. Communications Law §30A opt-in for marketing communications is not triggered at MVP (no advertising of any kind is served).

Provisions for other regions are set out in Appendix A — Region-specific provisions, §4.2, at the end of this policy.

§5 Who we share it with (sub-processors)

bGuru relies on a small number of third-party sub-processors to provide the Service. We name them all explicitly: Supabase (Frankfurt — Postgres, auth, storage), OneSignal (push notifications), Sentry (EU region — crash reporting), API-Football (sports data feed — no user data transmitted), Apple (App Store + APNs), Google (Play Store + FCM), Cloudflare (mini-site CDN + DDoS). Google LLC (AdMob) is not an active sub-processor at this version of the Service; the AdMob SDK was removed from the MVP codebase on 2026-06-08 and will be re-introduced in v1.1+ with advance notice.

For each sub-processor: the data categories transferred, the purpose, the data residency, and the data-processing agreement (DPA) link are published at bguru.app/legal/subprocessors.

When we add a sub-processor that materially changes the categories of data processed or the data-residency posture, we notify users via the §11 material-change notice flow (30-day notice, in-app banner + email).

We do NOT sell or share Personal Data within the meaning of CCPA/CPRA (Cal. Civ. Code § 1798.140(ad) "sell" or § 1798.140(ah) "share for cross-context behavioural advertising"), VCDPA, CPA, or any other US state law. At this version of the Service, no advertising SDK is active and no data is transmitted to any ad network; the CCPA/CPRA sell/share analysis is straightforward — neither definition is triggered. If advertising is introduced in a future version (planned v1.1+), the "Do Not Sell or Share" link, GPC-signal honouring, and Universal Opt-Out Mechanism / UOM support will all be activated before the change ships, via the §11 material-change notice flow.

§6 International data transfers

bGuru's primary data infrastructure is in Frankfurt, Germany (Supabase EU region), and most sub-processors are also EU-based or hold appropriate transfer safeguards. The paragraphs below describe the legal mechanism for transfers from each major jurisdiction.

Sub-sections §6.1 and §6.2 cover other regions and are set out in Appendix A — Region-specific provisions, at the end of this policy. Section numbers there are unchanged, which is why the numbering below skips.

§6.3 Israel — transfers to EU and to US sub-processors

For Israeli users, transfers are governed by the Privacy Protection Regulations (Transfer of Data Abroad) 5761-2001 / תקנות הגנת הפרטיות (העברת מידע אל מחוץ לגבולות המדינה), תשס"א-2001 + Amendment 13 transfer provisions. Transfers to countries on the PPA's adequacy list (which includes EU/EEA member states) are permitted without additional formalities — bGuru's transfers to Supabase Frankfurt and Sentry EU fall within this channel. Transfers to non-adequate countries (OneSignal US, Cloudflare US) are made under a data-processing agreement that imposes PPL-equivalent protections on the recipient (Israeli equivalent of the SCC mechanism); OneSignal's and Cloudflare's DPAs also incorporate EU SCCs, which the PPA accepts as compatible contractual safeguards.

API-Football: server-side only, no personal data of bGuru users is transmitted; outside the Regulations' scope.

§7 How long we keep your data

The retention period varies by data category. Where multiple bases for retention apply (e.g., a user account is active AND under legal-hold), the longest applicable period applies.

Data category	Retention
Account data (email, display name, password hash, OAuth token, profile fields)	Indefinite while account is active; 30-day grace period after a voluntary deletion request, then hard-deleted per ToS §10. An account removed for not meeting the minimum age runs a different, shorter clock — see the next three rows.
Date of birth	Held for the life of the account, as the record of the age check described in §9.1. Deleted with the account. Not used for anything other than establishing that the minimum age is met.
Account data where the account is removed for not meeting the minimum age (§9.1)	Access suspended immediately on computation. Deletion 72 hours after that — not the 30-day voluntary-deletion grace period. Extended only while a correction request or appeal is open, to an absolute maximum of 30 days from the request, after which deletion proceeds whether or not we have decided (GDPR Art. 18(1)(a) restriction while accuracy is contested; Art. 18(2) permits the continued storage). Suspension is never lifted by the extension.
Date-of-birth correction requests and appeals (dates requested, your explanation, the decision, the reasoning, who decided)	24 months from the decision, then deleted. Kept detached from the account — where the account has been deleted, the record survives it with no link back to a person. Purpose: demonstrating that a determination affecting someone's access was contestable, was contested, and was decided against a written standard; and detecting patterns in our own decisions per §9.6. Business need: without it, an adverse decision leaves no evidence it was ever reviewed.
One-way fingerprint of an email address blocked for not meeting the minimum age	The shorter of (a) the date the person would reach 16, or (b) 12 months from the block. Deleted automatically by a scheduled job at the end of that period. Purpose: preventing immediate re-registration of the same address with a different date. Business need: it is the only control that survives the deletion of the account itself; nothing else identifies a returning address. The value is a salted hash — it cannot be reversed into an address, cannot be used to contact anyone, and is not shared. See §9.2 for why a 12-month ceiling applies rather than the full period to age 16.
Predictions, picks, conviction scores	Indefinite while account is active; severed from your identity on hard-deletion (anonymised aggregates retained — no longer Personal Data)
Group memberships, follows, comments, reactions	Same as Predictions
Push notification tokens + preferences	Until you revoke consent (via Settings or device system settings) or account deletion completes
Sentry crash + performance data	30 days (Sentry default; matches the free Developer tier)
Product analytics data (event name, screen name, timestamp, session id, platform, app version, structured context)	Raw, identity-linked events: 12 months on an automated rolling purge. Aggregated, de-identified statistics derived from these events: indefinite — no longer Personal Data once de-identified (same standard as the row below). Also deleted immediately and in full on account deletion, regardless of the 12-month window.
Connection data (IP, session JWT)	Transient — IP held in memory for rate-limiting ~24 hours; JWT lifespan controlled by Supabase Auth (rotates on sign-out)
Account-deletion records (timestamps, grace-period state)	Retained for as long as required to demonstrate compliance with statutory erasure obligations; minimum 12 months
Backups	Per Supabase backup-rotation cycle (default 7 days); deletion requests are honoured against backups as the rotation cycles
Aggregated, de-identified statistics	Indefinite — no longer Personal Data once de-identified per the standards in GDPR Recital 26 + IL PPL guidance

§8 Your rights

§8.1 Rights you have everywhere

Regardless of jurisdiction, you have the following rights over your Personal Data held by bGuru:

• Access — see what we have about you.
• Rectification / correction — fix what's wrong.
• Erasure / deletion — ask us to delete (subject to legal-obligation exceptions; see Terms of Service, §10 Account deletion).
• Restriction of processing — ask us to pause processing while a dispute is resolved. This is not theoretical: contesting a date of birth under §9.1 pauses the deletion of your account for as long as we are considering it, up to 30 days.
• Objection — object to processing based on legitimate interest (currently only Sentry crash data).
• Portability — receive a copy of the data you've provided to us in a structured, machine-readable format (manual export at MVP; in-app export planned for a future version).
• Withdraw consent — for processing based on consent (push notifications), at any time, without affecting the lawfulness of prior processing.

How to exercise (any jurisdiction):

1. In-app: Settings → Privacy → Exercise rights (where available)
2. Email: legal@bguru.app (include your account email + which right you're exercising)
3. We respond within one month per GDPR Art. 12(3) and equivalent obligations, with a two-month extension where the request is complex (you'll be notified of any extension within the first month).

§8.2 Jurisdiction-specific rights

Israel (PPL Amendment 13 §§13–17). Right of access (§13), right of correction (§14), right of deletion (§17 — cross-ref ToS §10), right to data portability (§15A — Amendment 13's portability right; honoured by manual export at MVP, in-app automated export planned for a future version), right to object / restrict processing (§16). Right to complain to the Privacy Protection Authority (PPA / רשות להגנת הפרטיות): 3 Kaplan Street, Jerusalem 9195020; gov.il/en/departments/the_privacy_protection_authority; rmot.regulation@justice.gov.il. Israeli-resident consumers retain the right to bring proceedings in any Israeli court of competent jurisdiction in their district of residence (see ToS §15.1).

Provisions for other regions are set out in Appendix A — Region-specific provisions, §8.2, at the end of this policy.

§9 Children's data

§9.1 Coordinator framing

bGuru sets a flat minimum age of 16 in all jurisdictions in which the Service is available (see Terms of Service, §3 Age eligibility). bGuru does not knowingly collect Personal Data from any user under 16.

How the minimum age is established, and what happens if an account does not meet it. After you sign in for the first time, bGuru asks you for your date of birth on a neutral date-entry screen — no date is pre-filled, so nothing on the screen suggests an answer that would pass. Your age is calculated on our server, not in the app. The date is stored once and cannot be edited from within the app afterwards; the correction route described below exists for exactly that reason.

If the date you give computes to under 16, three things happen, in this order:

1. Access is suspended immediately — at the moment the age is computed, not at the end of any waiting period. The account stops functioning straight away. There is no window during which an account we have determined to be under-age keeps working.
2. The account is scheduled for deletion on a short clock (72 hours), and the deletion is not cancellable in the way a voluntary deletion request is. This is a shorter clock than the 30-day grace period that applies when an adult user chooses to delete their own account (see Terms of Service, §10) — deliberately so; a confirmed under-age account is not a choice being reconsidered.
3. You are told, in the app, what happened and how to contest it. The outcome is held as account state on our server, so it is still there the next time you open the app. We do not rely on a push notification or an email to deliver it.

If the date is wrong, you can contest it — and doing so pauses the deletion. A date of birth can be mistyped, and a wrong one has a severe consequence, so there is a route to fix it: you may submit one correction request, giving the date you say is correct and a short explanation. A person reviews it. If that request is refused, you may appeal once, and the appeal is considered afresh rather than treated as the same decision asked twice.

While a correction request or appeal is open, the deletion is held — for as long as it takes us to decide, up to a maximum of 30 days. This is a restriction of processing while the accuracy of your data is contested (GDPR Art. 18(1)(a), and the equivalent right elsewhere; Art. 18(2) expressly permits us to keep storing data that is restricted in this way). Suspension is not lifted during the hold — only the deletion waits. The 30 days is an outer limit, not a target: if we have not decided by then, the deletion proceeds, because leaving an account we believe belongs to a child parked indefinitely would be its own problem. If the correction is accepted, the account is restored and the deletion is cancelled.

We decide these requests against a published standard, set out in §9.6.

For users found to be under 13 specifically, the additional COPPA-derived treatment in §9.2 applies. For users found to be aged 13–15 — above the COPPA threshold but below bGuru's own 16+ gate — the treatment above applies as bGuru's own contractual minimum age, and the same correction and appeal route is available on identical terms.

Important nuance for users aged 16–17. A small number of jurisdictions require parental consent for users under 18 (not just under 16) for the processing of their Personal Data: South Africa (POPIA s. 35), UAE (PDPL Art. 8), Mexico (LFPDPPP + Mexican civil law), and several LATAM/MENA jurisdictions. bGuru's 16+ gate does not eliminate the under-18 parental-consent requirement in these jurisdictions. At MVP, bGuru applies the most restrictive data-minimisation and no-behavioural-targeting treatment to all users under 18 globally as a partial mitigation; the parental-consent gap for 16–17 users in these specific jurisdictions is a calibrated risk acceptance under the same pattern as the Art. 27 representative deferral. The v1.1 parental-consent provider integration will close this gap.

The under-13 hard-delete standard above is drawn from COPPA (15 U.S.C. §§ 6501–6506; 16 CFR Part 312) and is applied to every user worldwide, not only to users in the United States; see Appendix A §9.2 for the US state minor-data-law analysis. The same maximum-protection defaults described above apply to users aged 16–17 everywhere, not only in the jurisdictions named in this section; see Appendix A §9.4 for the under-18 analysis specific to Japan, South Korea, Singapore, New Zealand, South Africa, the UAE, Mexico, and the LATAM and MENA clusters.

Sub-sections §9.2 and §9.4 cover other regions and are set out in Appendix A — Region-specific provisions, at the end of this policy. Section numbers there are unchanged, which is why the numbering below skips.

§9.3 United Kingdom + European Union — under-18 protections at the 16+ baseline

United Kingdom (ICO Age Appropriate Design Code). The ICO Children's Code (issued under DPA 2018 s. 123) applies to any online service "likely to be accessed by children" — defined as persons under 18 — regardless of the minimum age set by the service. Because bGuru's 16+ gate still admits users aged 16-17, the Code applies. bGuru designs its Service to meet the Code's 15 standards for 16- and 17-year-old users:

• No profiling of under-18 users for behavioural advertising, interest-based targeting, or any purpose unrelated to providing the prediction and social-ranking features.
• No profiling-based, behavioral, or interest-based advertising to any user under 18 at any version (the restriction is at under-18, not merely under-16). At this version of the Service no advertising is served. When advertising is re-introduced in v1.1+, bGuru will apply appropriate age-restricted ad-treatment settings for users registered as 16 or 17, ensuring no IDFA or GAID is read for those users and no behavioral profiling occurs.
• Default privacy settings — not age-conditioned at this version of the Service, stated plainly. profile_visibility defaults to public for every account regardless of age (migration M046), and leaderboard visibility (leaderboard_visible) defaults to visible for every account regardless of age (migration M013) — bGuru's schema has no intermediate "followers-only" state for either setting; the only values are public/private for profile visibility and a plain visible/hidden boolean for the leaderboard. A more protective default for a computed-minor account (once the DOB architecture can identify one) is a recommendation under evaluation, not yet built — see docs/legal/_research/age-gating-strategy.md §4.3/§12.1. Every user, including those aged 16 and 17, receives the same defaults today as every other user and can change either setting manually at any time via Settings → Privacy.
• Data minimisation for under-18 users: only what is strictly necessary to provide the Service.
• No nudge techniques, no compulsive-use gamification mechanics, no default-on notifications for users under 18.

bGuru's 16+ baseline exceeds the UK digital-consent age of 13 (set by DPA 2018 s. 9 and confirmed by the DPDI Act 2025), but that higher sign-up age does not exempt bGuru from its Children's Code duties towards 16-17 year-old users.

European Union / EEA (GDPR Art. 8 + DSA Art. 28). GDPR Art. 8 sets the digital-consent age between 13 and 16 by member state; bGuru's flat 16+ gate is at-or-above every EU/EEA member state's Art. 8 threshold, so no per-member-state parental-consent flow is required at this version of the Service. For users aged 16 and 17, DSA Art. 28 (Regulation (EU) 2022/2065) requires online platforms to implement appropriate and proportionate measures to ensure a high level of privacy, safety, and security for minors. bGuru's compliance rests on: (i) no algorithmic content-recommendation feed and no personalisation system based on profiling — the Art. 28(2) recommender-system interface-design obligations do not apply; (ii) no profiling-based or behavioral advertising to any user under 18 at any version of the Service — DSA Art. 28(2) specifically prohibits profiling-based advertising to known minors; bGuru satisfies this at MVP because no advertising of any kind is served (AdMob SDK removed 2026-06-08); when advertising is re-introduced in v1.1+, age-restricted ad-treatment settings will be applied for users registered as 16 or 17 before any ad serves; (iii) no profiling of under-18 users for purposes beyond the core Service. bGuru will reassess if an algorithmic-feed or profiling-based advertising feature is introduced.

§9.5 Israel — the launch market

The Privacy Protection Law 5741-1981 sets no fixed digital-consent age. Unlike GDPR Art. 8, Israeli privacy law does not name a specific age at which a person may click "I agree" to an information-society service. bGuru's 16+ minimum age (see Terms of Service, §3 Age eligibility) applies to Israeli users the same way it applies to every other user of the Service — it is bGuru's own contractual floor, not a floor the PPL itself requires, and it sits well above the general routine-transaction test under the Legal Capacity and Guardianship Law 5722-1962 that would otherwise govern a minor's ability to use a free, no-cost service like bGuru. bGuru does not knowingly collect Personal Data from any Israeli user under 16, and applies the same hard-delete-on-discovery treatment described in §9.1 to Israeli accounts found to be under 16.

Israeli Privacy Protection Authority (PPA) draft age-assurance guidance. The PPA published draft guidance on online age assurance in June 2026 (the exact publication date is reported differently by different sources — 11 June 2026 in one, 28 June 2026 in another; both agree on the month). The guidance is a draft, open for public comment, and not binding. Its own text states the PPA is "not aware of any [Israeli] legal obligation" requiring age-assurance mechanisms more intrusive than self-declaration for a service like bGuru's. It sets out a three-tier framework for how a service might establish a user's age — self-declaration, age estimation, and age verification — without yet stating which tier applies to which kind of service. bGuru is monitoring this guidance and will reassess its own age-establishment mechanism against the final version once it is published; nothing in the draft currently requires a change to bGuru's posture.

§9.6 How we decide a date-of-birth correction

We publish the standard we decide these against, because a review process whose rule is not written down is not a safeguard — it is a form.

The test. We refuse a correction only if we conclude that the date already on file is more likely than not accurate, judged on the totality of the circumstances. This is the standard set out in the California CCPA regulations for contested personal information (11 CCR §7023(b)), and we apply it to every user, in every market, rather than only to Californians — it is the clearest written formulation of this decision we found anywhere, and having one rule is better than having several.

What that means in practice. We are not deciding whether we believe you are over 16. We are deciding whether the date entered originally is wrong. Two things follow, and they pull in opposite directions on purpose:

• A date of birth that you supplied about yourself, directly, on a screen with no pre-filled answer, is reasonably reliable evidence. So a correction request that offers only a different date, with no account of how the first one came to be wrong, will not usually succeed.
• We hold no document that proves the original date either, and we do not ask you for one — demanding identity documents from a free service that has never asked for them would collect far more sensitive data than the question warrants, and would be out of proportion to what is being decided. The regulation we follow contemplates this directly: where a business is not the source of the information and has no documentation supporting it, a person's own assertion that it is inaccurate may be enough.

Because of that second point, the question that usually decides the outcome is whether the correction describes a mistake a person plausibly makes when typing a date — two digits transposed, day and month the wrong way round, one digit out, the year entered in the wrong field. A correction of that shape is credible. A correction that simply moves the date to a figure just clearing 16, with no typing mistake that would produce it, is not.

If we cannot decide. If we cannot conclude that the date on file is probably accurate, we correct it. A genuine tie is not a finding that the record is right, and the standard only permits refusal on such a finding.

Where the date on file computes to under 13, the reviewer must additionally be able to identify which specific typing mistake they believe occurred, and record it. If they cannot, the request is refused at first instance and the reason given — and the appeal is then decided on the ordinary test above, without that additional requirement. We apply the extra step at that age because the consequence of getting it wrong is not a contractual one but a question of processing a child's data.

Every decision is written down — the outcome, and the reasoning, both when we refuse and when we agree. A recorded reason for agreeing matters as much as one for refusing.

Repeat requests. You get one correction request, and one appeal of it. A further request on the same facts may be refused as repetitive (GDPR Art. 12(5) and equivalents) — but a request that puts genuinely new information in front of us is not the same request, and will be looked at.

Nothing here is the end of the road. Our decision is not final and does not bind you. Whatever we decide, you keep every right described in §8 and every route of complaint in §8.2 and §12 — including complaining to your data-protection regulator and going to court. Any part of this section, or of the Terms of Service, that could be read as making our decision final, or as requiring you to accept it, does not have that effect and is not intended to.

§10 Security and breach notification

Security. bGuru implements reasonable technical and organisational measures appropriate to the risks of the processing, the nature of the Personal Data, and the size of the operation. These include: TLS in transit for all client–server and server–server traffic; encryption at rest (Supabase default); strict access control via JWT with short-lived sessions; password hashing (bcrypt via Supabase Auth, never stored in plaintext); the Sentry beforeSend PII-scrubber to prevent accidental logging of identifying data; periodic dependency-vulnerability scanning; sub-processor due diligence per the criteria in the sub-processor list; and the controls documented in the security section of the internal architecture documentation.

Internal access, including to private groups. A limited number of authorised bGuru personnel (platform administrators) can access account and group data through an internal administration tool — including content inside a group you have set to private — for purposes such as responding to a report, investigating a suspected breach of the Terms of Service or Community Guidelines, and the group-moderation actions described in Terms of Service §6: editing a group's name, description, or picture, and removing or reinstating a member other than the group's owner. Administrators do not change a group's privacy setting on the owner's behalf — only the owner controls that. Every administrative action that changes a group's details or membership is written to an internal log identifying which administrator took it, when, and what changed; administrators cannot edit or delete that log through the same tool. At this version of the Service, bGuru is a solo-developer project (see §2) — in practice, "authorised personnel" is the founder — and this paragraph is written to describe the access control itself, which does not depend on how many people currently hold it.

We comply with the New York SHIELD Act § 899-bb reasonable-safeguards obligation through these measures.

Breach notification. In the event of a Personal Data breach (defined as a security incident leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data — GDPR Art. 4(12) and equivalent), bGuru will notify the relevant supervisory authority and affected users in accordance with applicable law:

• GDPR Art. 33 (EU/EEA users) — supervisory-authority notification within 72 hours of awareness, unless the breach is unlikely to result in a risk to data subjects.
• GDPR Art. 34 (EU/EEA users) — direct user notification without undue delay when the breach is likely to result in a high risk.
• UK GDPR — same 72-hour SLA to the ICO.
• IL PPL Amendment 13 — without unnecessary delay; bGuru applies the GDPR-aligned 72-hour benchmark for the PPA as well (the PPA's implementing guidance permits up to 60 days for "severe security events" but the operational standard is faster).
• US state laws — without unreasonable delay (CA Civ. Code § 1798.82, NY SHIELD Act § 899-aa, and 48 other state breach-notification statutes); bGuru applies the same 72-hour benchmark uniformly.
• Rest of world — Australia 30 days (NDB scheme), New Zealand 72 hours (Privacy Act 2020 s. 114), Japan 3–5 days (APPI 2022 Art. 26), South Korea 72 hours (PIPA 2023 amendment), Singapore 3 calendar days (PDPA First Schedule), South Africa "as soon as reasonably possible" (POPIA s. 22), UAE "without undue delay" (PDPL + Executive Regulations 2024), MX/LATAM/MENA "without undue delay."

bGuru maintains an internal breach-notification playbook (regulator-notification template, user-notification template, hour-by-hour response) and applies a uniform 72-hour benchmark for all primary regulator notifications, regardless of jurisdiction, as the strictest binding SLA in the bGuru market portfolio.

§11 Changes to this Privacy Policy

We may change this Privacy Policy from time to time. For material changes — changes that meaningfully affect your rights or the way we process your Personal Data — we will give you at least 30 days' notice before the change takes effect, via an in-app banner shown the next time you sign in and (where you have provided an email address) by email. For non-material changes (typographical corrections, clarifications, references to new help-doc pages), we may publish an updated version without 30 days' notice; the updated last_updated date in the document header is the controlling indicator.

For changes required by mandatory law or by a genuine security or safety obligation that cannot reasonably be delayed, we may make the change effective immediately and notify you as soon as practicable thereafter (and in all cases within 7 days).

If you continue to use the Service after the effective date of a change, you are bound by the updated Privacy Policy. If you do not agree to a change, your remedy is to stop using the Service and to delete your Account (Terms of Service, §10 Account deletion).

EU/EEA users (DSA Art. 12). If you are a user in the EU/EEA, you have the right, during the 30-day notice period for any material change to this Privacy Policy, to terminate your use of the Service and to delete your Account under Terms of Service, §10 Account deletion free of any penalty. We will remind you of this right in any material-change notification.

§12 Contact us

For any data-protection inquiry — exercising your rights under §8, asking about anything in this Policy, or raising a concern about how we handle your data — contact us:

Email: legal@bguru.app In-app: Settings → Help → Contact Us

We respond within one month of receiving your inquiry per GDPR Art. 12(3) and equivalent obligations, and faster on urgent matters.

Sole-proprietorship posture. bGuru is currently operated as a sole-proprietorship project of an Israeli resident (see §2). The legal@bguru.app channel is staffed personally by the founder until the entity decision lands post-MVP, at which point a formal contact structure will be published via the §11 material-change notice mechanism.

EU/EEA users — Article 27 representative. We are working to appoint an EU/EEA representative under GDPR Article 27. The name, address, and contact details of our appointed representative will be published in this section once the appointment is confirmed (target: MVP+1). In the meantime, legal@bguru.app is the direct contact channel for EU/EEA users and supervisory authorities. You have the right to lodge a complaint with the supervisory authority of your member state of habitual residence — see §8.2 for the named EU/EEA supervisory authorities.

UK users — Article 27 representative. Same posture. legal@bguru.app is the interim channel. Complaints to the ICO per §8.2.

Israeli users — PPA contact. Complaints to the Privacy Protection Authority (PPA / רשות להגנת הפרטיות): 3 Kaplan Street, Jerusalem 9195020; gov.il/en/departments/the_privacy_protection_authority; rmot.regulation@justice.gov.il.

US users — state-specific contacts are in §8.2 (California Privacy Protection Agency / state Attorneys General). Federal: FTC for COPPA matters.

Rest of world — supervisory authority contacts are in §8.2 by jurisdiction.

Appendix A — Region-specific provisions

In this appendix: §3.2 data definitions · §4.2 lawful bases · §6.1 EU/EEA transfers · §6.2 United Kingdom transfers · §8.2 your rights · §9.2 United States (children's data) · §9.4 rest of world (children's data).

Placement in this appendix, or in the body above, reflects the internal structure of this Privacy Policy only. It is not a statement about whether, when, or for whom any provision applies — each provision addresses that for itself. Unless a specific paragraph below says otherwise, every commitment described in this appendix is one bGuru already applies today, for every user of the Service, regardless of where they are.

Moving a provision into this appendix does not withdraw it, weaken it, defer it, or amend it. Doing so is not, by itself, a change to this document under §11. Section numbers are unchanged: a cross-reference elsewhere in these documents — for example to §6.1 or §9.4 — resolves to the paragraph carrying that number below. Where the body above addresses a topic that also has a region-specific paragraph here, the body names that paragraph by number.

The rights in §8.1 apply to every user, in every region, at all times, and are not affected by this split.

§3.2 Jurisdiction-specific data definitions — other regions

European Union / EEA (GDPR Art. 4(1)). Under Regulation (EU) 2016/679 (GDPR), "personal data" means any information relating to an identified or identifiable natural person (a "data subject") — per Art. 4(1), a person is identifiable if they can be identified, directly or indirectly, by reference to an identifier such as a name, an identification number, location data, an online identifier (for example an IP address or a device token), or by reference to one or more factors specific to their physical, physiological, genetic, mental, economic, cultural, or social identity. GDPR Art. 9 defines a subset as "special category data" (racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data, data concerning health, data concerning sex life or sexual orientation) — bGuru does not collect any Art. 9 special category data. GDPR Art. 10 covers data on criminal convictions — bGuru does not process such data. Users in the EU/EEA should be aware that even data with no identifier attached can still be personal data within the meaning of Art. 4(1) if it could realistically be linked back to a person — for example, IP addresses held transiently for rate-limiting, or the device and crash-context metadata (model, OS version, stack traces) sent to Sentry, which carries no user or device identifier (see §3.1) but is still handled on a lawful basis described in §4 out of caution. Advertising posture (EU/EEA): At this version of the Service, bGuru does not run advertising. No ad SDK is active; no IDFA or GAID is requested; no TCF v2.2 CMP is required. If a future version introduces advertising (planned for v1.1+), bGuru will assess ePrivacy Art. 5(3) consent requirements, will evaluate whether TCF v2.2 / UMP integration is required, and will issue a 30-day material-change notice before any ad serves. No behavioral advertising will ever be served at any version of the Service. The no-advertising posture at this version means the §4.1 lawful-basis row for ad-impression data and the §4.2 AdMob legitimate-interest analysis are not operative at MVP.

United Kingdom (UK GDPR + DPA 2018 + DPDI Act 2025). For users in the UK, "personal data" means any information that relates to an identified or identifiable living individual, as defined in Article 4(1) of the UK GDPR (the retained UK version of Regulation (EU) 2016/679 as incorporated by the European Union (Withdrawal) Act 2018 and supplemented by the Data Protection Act 2018). That definition is substantively the same as its EU counterpart and is supplemented by Parts 2 and 3 of the DPA 2018 (which extend the framework to law-enforcement and intelligence contexts not relevant to bGuru). "Special category data" — heightened protection under UK GDPR Art. 9 and DPA 2018 Schedule 1 — is not collected by bGuru. The Data (Use and Access) Act 2025 has made targeted amendments to the UK framework since January 2025, principally reducing certain record-keeping burdens for lower-risk controllers and confirming the digital-consent age for information-society services at 13 under DPA 2018 s. 9; none of those amendments alter the definitions, the six lawful bases available to bGuru, or the rights set out in §8. The UK regulator is the Information Commissioner's Office (ICO). Advertising posture (UK): At this version of the Service, bGuru does not run advertising. No ad SDK is active; no IDFA is requested; no ATT prompt is triggered; PECR reg. 6 consent for ad delivery is not in scope. If a future version introduces advertising (planned for v1.1+), bGuru will assess PECR requirements and will issue a 30-day material-change notice before any ad serves. Profiling-based advertising will never be served to users under 18 at any version of the Service (see §9.3).

United States (COPPA + CCPA/CPRA + state laws). For US users, "personal information" carries distinct meanings across federal and state law. COPPA (15 U.S.C. § 6501(8)) defines personal information collected from a child under 13 to include name, postal address, email, telephone number, SSN, persistent identifiers (device IDs, session cookies, IP addresses used over time), and any photograph/video/audio of the child. bGuru's 16+ gate (§9) is designed so COPPA's verifiable-parental-consent obligations are never triggered. CCPA/CPRA (Cal. Civ. Code § 1798.140(v)(1)) defines personal information as any information that identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular consumer or household. The harmonised state-law definitions used in Virginia (VCDPA), Colorado (CPA), Connecticut (CTDPA), Utah (UCPA), Texas (TDPSA), Oregon (OCPA), Montana (MCDPA), New Jersey (NJDPA), Indiana (INDPA), Kentucky (KYDPA), Rhode Island (RIDTPPA), Tennessee (TIPA), Delaware (DPDPA), Iowa (ICDPA), Nebraska (NDPA), New Hampshire (NHPA), Maryland (MODPA) (which imposes stricter-than-baseline data-minimisation and profiling restrictions — bGuru's no-behavioural-targeting posture aligns), and Minnesota (MN MCDPA) each define "personal data" as information linked or reasonably linkable to an identified or identifiable natural person, excluding de-identified or publicly available information. The New York SHIELD Act (N.Y. Gen. Bus. Law § 899-aa) defines a narrower "private information" category focused on data-security. bGuru does not currently collect California-defined "sensitive personal information" (Cal. Civ. Code § 1798.140(ae)) — no SSNs, driver's licence numbers, financial-account credentials, precise geolocation, biometric data, health information, sexual orientation, or contents of private communications. Advertising posture (US): At this version of the Service, bGuru does not run advertising. No ad SDK is active; no data is transmitted to AdMob or any other ad network. bGuru does not sell or share personal data within the meaning of CCPA/CPRA. At this version, bGuru does not process the type of personal information for which the Global Privacy Control signal is operative under CCPA/CPRA §1798.135(b)(1). If a future version introduces advertising (planned for v1.1+), bGuru will: reassess the CCPA/CPRA sell/share analysis; activate the "Do Not Sell or Share" link; honour the GPC signal; and issue a 30-day material-change notice before any ad serves.

Rest of world (AU / JP / KR / SG / NZ / ZA / UAE / MX / LATAM / MENA / CH). Definitions converge: Australia Privacy Act 1988 App. 1 (APP 1) defines personal information as information about an identified or reasonably identifiable individual; Japan APPI Art. 2(1) (個人情報) covers information enabling identification including personal identification codes (個人識別符号); South Korea PIPA Art. 2(1) (개인정보) covers identifiable information including pseudonymous data that can be re-identified; Singapore PDPA §2 covers data about an identifiable individual; New Zealand Privacy Act 2020 §7 covers information about an identifiable individual; South Africa POPIA §1 covers information relating to an identifiable, living, natural person; UAE Federal Decree-Law No. 45 of 2021 Art. 1 plus DIFC DPL 2020 Art. 1 and ADGM DPR 2021 (the latter two GDPR-aligned); Mexico LFPDPPP Art. 3(V) covers identified or identifiable natural persons (sensitive data under Art. 3(VI)); other LATAM (Argentina Law 25.326 Art. 2; Chile Law 21.719 Art. 2; Colombia Ley 1581/2012 Art. 3; Peru Law 29.733 Art. 2) and other MENA (Saudi PDPL Art. 1; Egypt Law 151/2020 Art. 2; Morocco Law 09-08 Art. 1; Qatar Law 13/2016 Art. 1; Kuwait Reg. 12/2024 Sec. 1) all use functionally equivalent definitions. Switzerland revFADP Art. 5(a) is materially GDPR-aligned. Advertising posture (Australia and other rest-of-world markets): At this version of the Service, bGuru does not run advertising. No ad SDK is active; no IDFA or GAID is requested or transmitted. If a future version introduces advertising (planned for v1.1+), bGuru will reassess APP 7 direct-marketing obligations (AU), relevant cross-border consent requirements (JP APPI Art. 27), and equivalent obligations in other jurisdictions, and will issue a 30-day material-change notice before any ad serves.

Forward-looking (deferred markets): Brazil LGPD Art. 5(I); India DPDP Act 2023 §2(t) — both will apply when those markets open at v1.1.

§4.2 Jurisdiction-specific lawful bases — other regions

European Union / EEA (GDPR Art. 6). Account creation, predictions, groups, and leaderboards are necessary for the performance of the contract per Art. 6(1)(b). Sentry crash data is processed on the basis of legitimate interests per Art. 6(1)(f) — bGuru's interest in maintaining a stable, secure service; the balancing test favours this basis because the data is minimal, retained for at most 30 days (Sentry's default), processed in the EU region (Sentry EU deployment), and carries no identifier of any kind — direct (email, display name) or indirect (account ID, device ID) — capable of singling out an individual user; Sentry's IP-address inference is also disabled at the SDK level, so not even the device's network address is collected. Because no such linkage exists, a data subject cannot be re-identified from a Sentry crash report by bGuru or by Sentry, which weighs more strongly in favour of legitimate interest than a design retaining even a pseudonymous identifier would. bGuru does not collect location at this version of the Service (see §3.1); a future, optional device-location feature would run on consent per Art. 6(1)(a), not on legitimate interest, and this paragraph will be updated before it ships. Push notification delivery is processed on the basis of freely given, specific, informed, unambiguous consent per Art. 6(1)(a); consent may be withdrawn at any time via Settings, and withdrawal does not affect the lawfulness of prior processing per Art. 7(3). Account-deletion records are retained under legal obligation per Art. 6(1)(c) and the Art. 17(3)(b) and (e) exceptions. No advertising processing at this version — advertising is deferred to v1.1+; when re-introduced, the applicable lawful basis and balancing-test analysis will be added here before any ad serves.

United Kingdom (UK GDPR Art. 6). Same mapping as EU/EEA for account, social, Sentry, push, and deletion data. The ICO's "legitimate interests balancing test" has been applied for the Sentry processing (see EU/EEA analysis above — same data minimisation and EU-region posture applies). No advertising processing at this version — advertising is deferred to v1.1+; when re-introduced, the PECR reg. 6 analysis and ICO LIA documentation will be prepared and added here before any ad serves.

§6.1 European Union / EEA — transfers to Israel and to US sub-processors

bGuru is currently operated from Israel. Israel holds an EU Commission adequacy decision (Commission Decision 2011/61/EU of 31 January 2011, transitioned under GDPR Art. 45(9) and confirmed by the Commission's January 2024 periodic review of pre-GDPR adequacy decisions). Transfers from the EU/EEA to bGuru's Israeli controller therefore do not require Standard Contractual Clauses — the adequacy channel applies. (For the avoidance of doubt: if the adequacy decision were to be withdrawn or expire, SCCs Annex I-III per Implementing Decision (EU) 2021/914 plus supplementary measures per Schrems II would apply as a fallback; this Policy will be updated immediately if the adequacy status changes.)

For sub-processors located outside the EU/EEA:

• Supabase — data hosted in Frankfurt (AWS eu-central-1); no third-country transfer occurs.
• Sentry — EU region (Frankfurt); no third-country transfer occurs.
• OneSignal (US) — transfers under Module 2 SCCs (controller-to-processor) per Implementing Decision (EU) 2021/914, supplemented by OneSignal's EU-US Data Privacy Framework (DPF) certification where active.
• Cloudflare (US) — SCCs per Implementing Decision (EU) 2021/914; Cloudflare also holds DPF certification, which the ICO and Commission have assessed as providing essentially equivalent protection for EEA-to-US transfers.

A copy of the SCCs in force for each sub-processor is available on request via legal@bguru.app.

§6.2 United Kingdom — transfers to Israel and to US sub-processors

For UK users, transfers outside the UK are governed by Chapter V of the UK GDPR. Israel benefits from a UK adequacy regulation made under DPA 2018 s. 17A (reflecting the original EU adequacy decision and maintained in UK domestic law post-Brexit, per Schedule 3 to the UK GDPR (Application, Corrections and Adaptations) Regulations 2019). UK-to-Israel transfers therefore do not require additional safeguards under UK GDPR.

For US-based sub-processors (OneSignal, Cloudflare), bGuru relies on either (a) the International Data Transfer Agreement (IDTA, the UK's post-Brexit successor to the EU SCCs) issued by the Secretary of State under DPA 2018 s. 119A, or (b) the UK Addendum to the EU SCCs (ICO-issued, appended to EU SCCs Decision 2021/914), supplemented by a UK Transfer Risk Assessment (TRA) per ICO guidance. Each of bGuru's US-based sub-processors currently holds EU-US DPF certification, which the ICO has assessed as providing essentially equivalent protection; SCCs/IDTA serve as a contractual backstop.

§8.2 Jurisdiction-specific rights — other regions

European Union / EEA (GDPR Art. 15–22). Specific rights: access (Art. 15), rectification (Art. 16), erasure / "right to be forgotten" (Art. 17 — cross-ref ToS §10 + Art. 17(3) exceptions), restriction (Art. 18), portability (Art. 20 — structured, commonly-used, machine-readable format), objection (Art. 21 — including to the Sentry processing described in §4.2), automated-decision-making rights (Art. 22 — bGuru does not make solely-automated significant decisions about individuals; the prediction engine generates probabilities for sports events, not decisions about you). Right to complain to the supervisory authority in your member state of habitual residence — for example, the Data Protection Commission (DPC) in Ireland (dataprotection.ie), the Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI) in Germany (bfdi.bund.de), the Garante per la protezione dei dati personali in Italy (garanteprivacy.it), Agencia Española de Protección de Datos (AEPD) in Spain (aepd.es), or the supervisory authority of any other EU/EEA member state in which bGuru has an establishment or the place of processing.

United Kingdom (UK GDPR Art. 15–22 + DPA 2018). Same rights as EU/EEA. UK-specific complaint channel: Information Commissioner's Office (ICO): Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF; casework@ico.org.uk; 0303 123 1113; ico.org.uk/make-a-complaint. You also have the right to bring proceedings in the courts of England and Wales (or Scotland, or Northern Ireland, as applicable) if you consider bGuru has infringed your rights, independently of any ICO complaint.

United States — California (CCPA/CPRA, Cal. Civ. Code §§ 1798.100–1798.199.100). Right to know (§ 1798.110), right to delete (§ 1798.105 — subject to the § 1798.105(d) exceptions), right to correct (§ 1798.106), right to opt out of sale/sharing (§ 1798.120 — bGuru does not currently sell or share within these statutory meanings; if this ever changes, the "Do Not Sell or Share" link + GPC-signal honouring will be activated before the change), right to limit use of sensitive PI (§ 1798.121 — bGuru does not currently process sensitive PI per §3.2 US), right to non-discrimination (§ 1798.125). Data-breach private right of action (§ 1798.150 — statutory damages $100-$750 per consumer per incident or actual damages, plus injunctive/declaratory relief, for failure to implement reasonable security). Shine the Light (§ 1798.83 — request via legal@bguru.app subject line "Shine the Light Request"; bGuru does not currently share PI with third parties for their own direct marketing). Global Privacy Control (GPC): At this version of the Service, bGuru does not process the type of personal information for which GPC is operative under CCPA/CPRA §1798.135(b)(1) — no advertising SDK is active and no behavioral data is shared with any ad network. If a future version introduces advertising (planned v1.1+), GPC will be honoured as a valid opt-out signal per CPPA Final Regulations § 7025(c) before any ad SDK activates. Complaints to the California Privacy Protection Agency (CPPA) at cppa.ca.gov/complaints.

United States — other states (VCDPA / CPA / CTDPA / UCPA / TDPSA / OCPA / MCDPA (MT) / NJDPA / INDPA / KYDPA / RIDTPPA / TIPA / DPDPA / ICDPA / NDPA / NHPA / MODPA / MN MCDPA). Residents of Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, New Jersey, Indiana, Kentucky, Rhode Island, Tennessee, Delaware, Iowa, Nebraska, New Hampshire, Maryland (MODPA — heightened data-minimisation + profiling restrictions; bGuru's posture aligns), and Minnesota have rights mirroring the CCPA framework: access, correction, deletion, opt-out of sale + targeted advertising + profiling (bGuru does not engage in any of these three at MVP), and portability. Colorado CPA (C.R.S. § 6-1-1315) requires honouring the Universal Opt-Out Mechanism (UOM); bGuru will honour this when any targeted-advertising or sale of personal data begins (not applicable at MVP — no advertising SDK is active). Enforcement is by each state's Attorney General; none of these state laws provides a private right of action (in contrast to CCPA § 1798.150 for data-breach claims). Request channel: same as universal (Settings or legal@bguru.app), subject line "US Privacy Rights Request" + state. Response within 45 days (CCPA outer limit + state equivalents), with one 45-day extension on notice.

United States — New York (SHIELD Act, NY GBL §§ 349–350, SAFE for Kids Act). SHIELD Act (N.Y. Gen. Bus. Law § 899-aa, § 899-bb) imposes data-security obligations on businesses holding NY residents' "private information"; bGuru's reasonable safeguards under § 899-bb are described in §10. Breach-notification under § 899-aa is addressed in §10; bGuru applies the strictest 72-hour benchmark for primary regulator notifications. NY GBL §§ 349-350 (deceptive acts and false advertising) preserves NY residents' private right of action ($50 minimum, up to $1,000 for wilful violations, plus attorneys' fees). NY SAFE for Kids Act (2024 — not yet in effect; final implementing rules were published by the New York Attorney General on 28–29 July 2026, and the Act's substantive obligations become operative 25 January 2027) — bGuru does not operate an algorithmic content-recommendation feed, so it is not currently a "social media platform" within the Act; if this changes, bGuru will assess compliance before the change ships and, in any case, before the Act's own 25 January 2027 effective date.

Rest of world — your rights by jurisdiction.

• Australia (Privacy Act 1988, APPs 12–13): right of access (APP 12) and right of correction (APP 13). Complaints to the Office of the Australian Information Commissioner (OAIC) at oaic.gov.au.
• Japan (APPI Arts. 28–35, as amended 2022): disclosure (Art. 33), correction (Art. 34), addition/deletion (Art. 34), suspension of use (Art. 35), third-party-provision stoppage (Art. 35), erasure (Art. 35). Complaints to the Personal Information Protection Commission (PPC, 個人情報保護委員会) at ppc.go.jp.
• South Korea (PIPA Arts. 35–39): access (Art. 35), correction/deletion (Art. 36), suspension (Art. 37), compensation (Art. 38), complaints (Art. 39). Complaints to the Personal Information Protection Commission (PIPC, 개인정보보호위원회) or the Korea Internet & Security Agency (KISA) at privacy.go.kr.
• Singapore (PDPA, Part V — Access and Correction Obligation): access (§ 21), correction (§ 22). 30-day response (extendable). Complaints to the Personal Data Protection Commission (PDPC) at pdpc.gov.sg.
• New Zealand (Privacy Act 2020, IPP 6–7): access (IPP 6), correction (IPP 7). Complaints to the Office of the Privacy Commissioner (OPC) at privacy.org.nz.
• South Africa (POPIA §§ 23–25): notification (§ 23), correction/destruction/deletion (§ 24), record of correction request (§ 25). Complaints to the Information Regulator (South Africa) at inforegulator.org.za.
• UAE (UAE PDPL Arts. 13–19; DIFC DPL 2020; ADGM DPR 2021): access (Art. 13), correction (Art. 14), erasure (Art. 15), restriction (Art. 16), portability (Art. 17), objection (Art. 18). 30-day response. Complaints to the UAE Data Office, DIFC Commissioner of Data Protection, or ADGM Registration Authority as applicable.
• Mexico (LFPDPPP Arts. 22–29 — ARCO rights): Access (Acceso), Rectification (Rectificación), Cancellation (Cancelación), Opposition (Oposición). 20-business-day response, 15-business-day implementation. Complaints to INAI at inai.org.mx.
• Other LATAM (AR / CL / PE / CO): rights are functionally equivalent to ARCO (access, rectification, suppression/cancellation, objection). Argentina — AAIP enforcement; Chile — Law 21.719 (fully effective 2026); Colombia — SIC; Peru — APDP. Same channel: legal@bguru.app.
• Other MENA (SA / EG / MA / QA / KW): access + correction + erasure + objection rights under each national PDPL. Same channel: legal@bguru.app. 30-day response standard.
• Switzerland: revFADP Art. 25 (access right), Art. 32 (rectification + erasure rights). The Federal Data Protection and Information Commissioner (FDPIC) enforces.

Forward-looking (deferred markets — v1.1): When Brazil opens, LGPD Arts. 17–22 rights will apply (ANPD enforcement). When India opens, DPDP Act 2023 ss. 11–14 rights will apply (Data Protection Board enforcement, once constituted). When Canada opens (excluding Quebec until FR-CA translation lands), PIPEDA + provincial laws will apply. When France or Belgium re-open, GDPR rights described above will apply per CNIL / APD-GBA / DGCN respectively.

§9.2 United States — COPPA hard-block and state minor-data laws

COPPA — federal hard-block for users under 13 (15 U.S.C. §§ 6501–6506; 16 CFR Part 312). bGuru is not directed to children under 13 and does not seek verifiable parental consent ("VPC"); bGuru's 16+ minimum age gate is designed to prevent any user under 13 from registering. If bGuru obtains actual knowledge that a registered user is under 13 (the COPPA standard, per 16 CFR § 312.3), bGuru will: (1) suspend access to the account immediately, at the moment the age is computed; (2) delete all personal information collected from or about that user from active systems on the expedited timetable described in §9.1 and quantified in the §7 retention table, except where retention is required to comply with a legal obligation, to exercise or defend legal claims, or for the two narrow purposes named in the next paragraph; (3) notify the parent or guardian if contact information is available; and (4) process any inadvertent paid-tier charge as a refund.

Two things survive that deletion, and both are named here rather than left implied. First, a record that a correction was requested and how it was decided, kept without the account it related to — so that the fact a person contested a determination, and the reasoning we applied, does not disappear along with the account when the outcome goes against them. Second, a one-way cryptographic fingerprint of the email address, which cannot be reversed into an address, cannot be used to contact anyone, and exists solely to stop the same address being used immediately to create a replacement account. Both are held for the fixed periods stated in the §7 retention table and are deleted automatically at the end of them. Neither is used for any other purpose, and neither is shared with anyone.

Why the fingerprint is capped at 12 months rather than held until the person turns 16. The obvious bound would be "keep it until they are old enough" — but for the youngest cases that means holding something derived from a child's data for the best part of a decade, and the purpose it serves does not last that long. What the fingerprint actually prevents is a person turning straight round and registering the same address again; that behaviour happens within days or weeks, not years. A 12-month ceiling covers it completely. It also matters that the longest retention would otherwise fall on the youngest people, which is the wrong way round. If the same address is used again after the fingerprint has expired, the age check in §9.1 applies again from scratch, on its own merits — the fingerprint was never what was doing that work.

Suspension is immediate; it is not, in every case, permanent. An earlier version of this Policy described the suspension as permanent. That was accurate to the design as it then stood, and is no longer accurate: a determination that rests on a date of birth can be wrong, and §9.1 now provides a route to contest it, with the deletion held while that is considered. If a correction is accepted, the account is restored. We have corrected the wording rather than leave a statement that overstates the finality of our own decision.

Nothing above requires COPPA's own text to be read as imposing a fixed number of days. 16 CFR §312.10 requires that a child's personal information be retained "only as long as is reasonably necessary to fulfil the purpose for which it was collected" and then deleted using reasonable measures; it sets no day-count. A previous version of this Policy said federal law "requires immediate deletion", which put a precision into the statute that is not there. The expedited timetable in §9.1 is bGuru's own implementation of the "reasonably necessary" standard, and the brief hold while an accuracy dispute is resolved is part of establishing whether the purpose — removing a child's data — is the one actually in play.

This hard-deletion obligation applies regardless of any parental consent obtained outside the Service; no VPC mechanism can authorise a sub-13 account under these Terms or this Policy. The FTC enforces COPPA. bGuru does not employ cookie-fingerprinting, device-fingerprinting, or any mechanism designed to identify users as minors for tracking or targeted-advertising purposes.

State minor-data laws (users under 18). California — SB-976 (KOSMA, Cal. Civ. Code § 1798.99.29 et seq.): bGuru's client-side gated push-notification prompt (explicit opt-in before any push notifications are sent) satisfies KOSMA's consent-before-notification requirement; bGuru does not currently operate an algorithmically curated content-recommendation feed, so is not currently a "social media platform" within KOSMA for the addictive-design restrictions. New York SAFE for Kids Act (2024 — not yet in effect; substantive obligations operative 25 January 2027 per the final AG rules published 28–29 July 2026): same analysis. Maryland MODPA (Md. Code Com. Law § 14-4601 et seq.): bGuru's no-behavioral-advertising posture + data-minimisation + no-profiling-of-under-18 alignment satisfies MODPA's heightened requirements. Colorado CPA minor-data provisions (C.R.S. § 6-1-1306(4)): bGuru does not sell PI and does not engage in targeted advertising. Florida HB 3 (2024, Fla. Stat. § 501.1736 et seq.): bGuru does not operate an algorithmic feed and is not currently within scope. Blanket policy: bGuru applies no-behavioural-targeting to all users under 18 globally, providing forward-looking compliance for any additional state minor-data laws enacted between updates of this Policy.

§9.4 Rest of world — under-18 protections by jurisdiction

Australia — not available at this version of the Service (moved to deferred, 2026-08-16). The Online Safety Amendment (Social Media Minimum Age) Act 2024 establishes 16 as the operative minimum age for a covered social media service, matching bGuru's own baseline exactly on the number — but the number matching is not, by itself, what determines whether bGuru is available in Australia. Two separate questions govern: (a) whether bGuru is a service covered by the Act's "age-restricted social media platform" definition at all, a test that turns on the service's own purpose and self-description rather than its declared minimum age; and (b) if covered, whether self-declaration of age — including the honest, server-enforced date-of-birth mechanism this version of the Service uses — satisfies the Australian eSafety Commissioner's binding "reasonable steps" compliance standard, which does not treat self-declaration as sufficient on its own, at any declared age. Because both questions remain open, bGuru does not make the Service available to Australian users at this version, and does not knowingly collect Personal Data from an Australian resident. The Privacy Act 1988's own protections (OAIC treats under-13 as requiring heightened protection) are unaffected by this and would in any event be satisfied by bGuru's 16+ baseline once Australia opens. Australia will be opened once the coverage question is resolved and, if bGuru is found to be covered, a compliant age-assurance mechanism beyond self-declaration has been implemented.

Japan. APPI does not set a fixed digital-services minimum age; common industry practice treats 16 as the operative threshold. bGuru's 16+ gate aligns.

South Korea. PIPA Art. 22(6) requires VPC for users under 14; bGuru's 16+ gate is above. For 16-17 year-old users (who are "youth" under the Youth Protection Act, 청소년 보호법), bGuru applies the same no-behavioural-targeting + explicit-opt-in posture as elsewhere, consistent with PIPA's strict opt-in regime.

Singapore + New Zealand. Neither PDPA nor Privacy Act 2020 sets a statutory minimum age for digital services; bGuru's 16+ gate exceeds the regulatory-guidance threshold (under-13 in SG; under-16 in NZ). Standard PDPA / Privacy Act 2020 protections apply for 16-17 users.

South Africa, UAE, Mexico, other LATAM, other MENA. POPIA s. 35, UAE PDPL Art. 8, LFPDPPP + Mexican civil law, and the LATAM/MENA cluster all require parental consent for users under 18. bGuru's 16+ gate does not eliminate this requirement for 16-17 year-old users in these jurisdictions. Calibrated risk acceptance at MVP — bGuru does not knowingly register users under 18 in these markets, applies maximum data-minimisation + no-behavioural-targeting treatment to all under-18 users globally, and will integrate a managed parental-consent provider at v1.1 to close this gap. Enforcement against indie operators for the 16-17 sub-band is rare; the documented mitigation posture is in the same risk class as the Art. 27 representative deferral.

Forward-looking (deferred markets — v1.1). Brazil — Digital ECA (Law 15.211/2025) imposes a hard block for under-12s, requires parental consent for 12-17, and prohibits profile-based advertising to under-18s; bGuru's planned parental-consent provider integration satisfies this. India — DPDP Act 2023 s. 9 requires VPC for under-18s; same v1.1 parental-consent provider integration. Canada — depending on which Path A/B is taken for the Quebec FR-language commitment, parental-consent flow may or may not be required at v1.1 entry. Australia — see the dedicated Australia paragraph above; unlike the other markets in this paragraph, its gap is not a parental-consent gap and will not be closed by the same v1.1 parental-consent provider integration — it needs its own resolution (a coverage determination and, if covered, a compliant age-assurance mechanism).

---

§13 Changelog

Version	Effective date	Changes
0.1.23	2026-08-27	All location collection removed. Having read location-e2e-review.md, the founder decided to remove the connection-based location feature shipped in 0.1.21/0.1.22 rather than expand it — a future version will ask for the device's own location instead, once, only with the user's explicit permission via the phone's own prompt, and only from the one screen that will actually need it (a local-standings tab, not yet built). Removed from this version, because there is nothing left for any of it to describe: the §3.1 "Location" data-collection bullet (replaced with a plain not-collected statement, and the Profile-fields bullet above it no longer points to it); the §4.1 lawful-basis row (now "not applicable — not collected"); the §4.2 Israel provisional-consent-basis text; the §5 Cloudflare location-relay description; the §7 retention row; and the §8.1 "Controlling who else sees your location" paragraph (returns once a future version restores the feature). §3.2 Israel and Appendix A §4.2 EU/EEA no longer discuss whether a connection-based location estimate falls under a heightened-protection tier — the open question those sections spent real length on in 0.1.21/0.1.22 has nothing left to apply to, because nothing is being collected. Every account's previously-detected or previously-guessed location (215 accounts carrying a country from the pre-2026-08-26 onboarding flow's device-locale guess, never disclosed to the user as a guess, plus the one test account stamped by the removed IP-based flow) was cleared from the database in the same change. Full reasoning + the five founder decisions: decisions-log.md, "User location — all collection removed; GPS-only opt-in deferred to local standings (2026-08-27)." Companion: sub-processor list v0.1.12.
0.1.22	2026-08-27	Founder escalation on the 0.1.21 location feature, answered. The founder asked, the day after 0.1.21 shipped, whether silently detecting a city for existing accounts — which only became possible once the GeoNames city import (G12b) landed the same day — was "legal approved," having concerns. Ruling: decisions-log.md, "User location — existing accounts, city, and the G12c re-detect (2026-08-27)." Two Policy corrections, both required regardless of how the open question below resolves. §3.2 Israel previously stated flatly that "bGuru does not collect any PPL sensitive information at MVP" — narrowed to name only the settled categories (health, biometric, genetic, sexual orientation, religious/political belief, racial origin, criminal history), because converging secondary sources (not yet checked against the primary statute) describe Amendment 13 as having extended its "highly sensitive information" tier to cover location and traffic data, and whether bGuru's coarse, one-time country/city estimate falls within that reading is genuinely open — stated as such, rather than asserted either way. §4.2 Israel's legitimate-purpose basis for location is now marked provisional pending that question; if it resolves to require consent, bGuru will add a consent step rather than continuing on legitimate purpose alone. §3.1 and §7 each gain one clarifying sentence: a detection can add a city to an account that already had a country from an earlier version of the app, without that counting as overwriting the country — a distinction the 0.1.21 text didn't spell out, and the reason the one-time in-app message (unchanged by this Policy update — it is a client-side copy fix, tracked separately, see the decisions-log entry) may currently mention only the country even when a city was written in the same step. No right or protection was narrowed by this update; two claims were corrected to what's actually settled, and one basis was marked provisional rather than asserted with more confidence than the underlying question currently supports.
0.1.21	2026-08-26	New: bGuru now detects an approximate location (country, and city once available) for every account, and this Policy discloses the mechanism for the first time. When you sign in on a version of the app that supports it, bGuru's own website asks Cloudflare (already a named sub-processor, §5) which country and city your connection appears to come from, based on your IP address at that moment; bGuru never receives or stores the IP address or the coordinates themselves — only the resulting country/city is saved, and you can keep or change it in a one-time in-app message, or at any time afterward in Settings → Profile. New §3.1 "Location (country, and city where available)" paragraph, placed right after Profile fields, which no longer separately names "home city" (it's covered by the new paragraph instead). The "We do NOT collect" list narrowed from a general "precise geolocation" line to state plainly what we still don't collect — continuous, background, or GPS location, and the underlying IP address or coordinates — which is a different claim from the coarse country/city estimate we do now collect. New §4.1 lawful-basis row (legitimate interest for automatic detection; contract performance when you set or change it yourself; consent reserved for a possible future GPS opt-in, not built at this version) — and the existing Account data row no longer separately lists "home city," to avoid two rows claiming two different bases for the same field. §4.2 Israel paragraph extended to include location among the legitimate-purpose data categories. §5 Cloudflare entry extended to describe the relay. New §7 retention row (life of the account; replaced when you change it; deleted with the account). §8.1 now names the pre-existing "Show my location" switch (Settings → Privacy) plainly for the first time, and states that it defaults off for any account known, from the date of birth described in §9.1, to belong to someone under 18 — the first field in this schema to receive an age-conditioned default. Appendix A §4.2 EU/EEA gained one sentence extending the Art. 6(1)(f) legitimate-interest analysis to location, for when that market re-opens. Rollout note: detection runs for every account, including accounts created before this version, the next time they sign in — not only new signups — and a detection can never overwrite a country a person already chose for themselves. The founder made this call knowing it means this update ships alongside the feature rather than the 30 days ahead of it that §11 would otherwise call for; the reasoning is recorded in full in docs/legal/_research/decisions-log.md, "User location — IP-derived country (G12, 2026-08-26)." Companion: sub-processor list v0.1.11.
0.1.20	2026-08-22	New §10 paragraph: bGuru's internal access to account and group data, including private groups, is disclosed for the first time. Nothing in this Policy previously said anything about it — §5 covers only third-party sub-processors, a different question from bGuru's own staff access to what users post. Since 2026-08-21 (migrations M248, M250, M257), a platform administrator can, on a user-created group, edit its name/description/picture and remove or reinstate a member other than the owner, reaching private groups the same as public ones; the new paragraph names the purpose (responding to reports, investigating breaches, the Terms of Service §6 group-moderation actions), states what administrators do NOT do (change a group's privacy setting, remove an owner), and describes the audit trail (who, when, what changed; not editable or deletable by the administrator it names). Companion disclosure: Terms of Service 0.1.18 §6/§9. A note on precision, following an incident. An earlier internal draft justified part of this disclosure by quoting this Policy as already promising "every such action is recorded with who did it, when, and what changed" — a sentence that does not exist and has never existed in any version of this document (confirmed by searching every commit). It was fabricated, reached three committed files on 2026-08-21, and was withdrawn in PR #609. This entry, and the §10 paragraph it describes, state only what is independently verifiable against the migrations named above and this document's own actually-published text.
0.1.19	2026-08-18	The age-gate correction route, and the removal of three statements that contradicted it. A five-jurisdiction review (Israel, UK, US, EU, rest-of-world) of the under-16 removal path found that this Policy described an outcome as immediate, permanent and unretained, while the mechanism being built holds deletion for up to 30 days, can be reversed, and keeps two things on purpose. Three specific statements were corrected, none of which had ever been true of the design as built: §9.1's "we hard-delete the account and associated Personal Data without further notice" (there is now notice, in-app and durable, and a route to contest); §9.2's "immediately and permanently suspend" (immediate, yes; permanent, not where a correction succeeds); and §9.2's "without retention of any identifying data" (a decision record and a one-way email fingerprint are both retained, deliberately, and are now disclosed with their purposes and periods rather than left unmentioned). Also corrected: this Policy said COPPA "requires immediate deletion" — 16 CFR §312.10 sets a "reasonably necessary" standard and no day-count at all, so the statute was being credited with a precision it does not have. New §9.1 detail describing how the age is established (neutral date entry after first sign-in, no pre-filled date, age computed server-side) and what follows a determination of under-16 — immediate suspension, a 72-hour deletion clock, and a hold on that deletion while a correction is open. New §9.6 publishes the standard those corrections are decided against, including that a genuine tie is resolved in the user's favour, that we do not ask for identity documents, and that our decision is not final and binds nobody. Four retention rows added and one amended in §7, giving real periods and stated purposes for the date of birth, the age-gate removal clock, the correction record (24 months) and the email fingerprint (12 months, capped deliberately below the period to age 16) — the disclosure form 16 CFR §312.10 asks for, and the numbers a reader could not previously have found anywhere. §8.1's restriction-of-processing bullet now points at the one case where the right actually bites.
0.1.18	2026-08-17	Frontmatter self-contradiction removed, matching the same fix in Terms of Service v0.1.16. The jurisdictions_in_scope catch-all read "Worldwide except geo-block list (RU/IR/KP/CU/SY/BY/TR/CN/HK/MO/sanctioned UA regions)" — a list that does not contain France, Belgium, Brazil, Canada, India or Australia, and so silently re-admitted the six jurisdictions that jurisdictions_deferred_v1_1 declares deferred in the very next block. Document body unchanged.
0.1.17	2026-08-17	Appendix A preface replaced, and §9.3 returned to the body — both required by a five-specialist review (EU, UK, US, Israel, rest-of-world) of the 0.1.16 restructure. The previous preface said region-specific provisions "take effect in its region on the day the Service becomes available there", which tied legal effect to app-store availability — the wrong trigger, since data-protection duties attach to processing a person's data, not to a launch announcement, and bGuru's web application is reachable worldwide. The replacement makes no applicability claim in either direction: placement says nothing about whether or when a provision applies, and the default is that every commitment in the appendix is one bGuru already applies today unless a specific paragraph says otherwise. §9.3 moved back into the body because its content is unconditional global under-18 product behaviour (no behavioural advertising to under-18s at any version, no default-on notifications, data minimisation) rather than UK/EU-gated law — appendix placement misdescribed protections that are live for every user today. §9.1 now names §9.2 and §9.4 explicitly, and the appendix gained an index. No right, obligation, or protection changed.
0.1.16	2026-08-17	Restructured so the provisions that apply where bGuru is available come first; region-specific provisions for markets not yet opened moved to the new Appendix A. Nothing was removed, weakened, or deferred. Israel now leads §3.2, §4.2, §6 and §8.2, and §9 runs §9.1 → §9.5 directly. The relocated blocks (§3.2, §4.2, §6.1, §6.2, §8.2, §9.2, §9.3, §9.4) keep their original section numbers in the appendix, so every existing cross-reference still resolves — deliberately, after the §11-insertion defect corrected in 0.1.15 showed what renumbering costs. Verified by a full vocabulary diff (zero words lost) and a rendered-HTML comparison (tables 3→3, rows 35→35, list items 74→74; only the appendix heading, three continuation headings and the pointer paragraphs added).
0.1.15	2026-08-17	Four stale Terms-of-Service cross-references corrected. The Terms of Service gained a new §11 (Third-party intellectual property) in an earlier release, which shifted every later section down by one — Geographic restrictions §13→§14, Governing law §14→§15, Changes §15→§16, Contact §16→§17 — but inbound cross-references were never updated. Each pointer below therefore sent readers to a real but wrong section. No right, obligation, or disclosure changed; this is a navigation fix. Fixed: §8.2 Israel (Israeli-court right) ToS §14.1→§15.1; the §11 ownership pointer ToS §15→§16; the §12 ownership pointer ToS §16→§17; and §2's 30-day material-change notice pointer ToS §15→§16.
0.1.14	2026-08-17	§9.3 URGENT correction, found by the 5-specialist debate round on the age-gating research-completion pass — a live falsehood in a published document. §9.3's UK bullet stated, present-tense and unconditionally, that "leaderboard visibility defaults to followers-only, profile visibility defaults to private" for under-18 users. Two specialists independently verified against the migration SQL that this is false: profile_visibility defaults to public for every account regardless of age (M046, 20260522000046_mobile_onboarding_columns.sql), leaderboard_visible defaults to true (visible) for every account regardless of age (M013, 20260428000013_settings_profile.sql), there is no age-conditioning anywhere in the schema, and — critically — no "followers-only" value exists in the schema at all, for either setting. This is not a documentation lag on a not-yet-shipped feature (the pattern that excuses this document's other forward-looking claims, e.g. the advertising paragraphs around this one); it was an affirmative, specific, checkable claim about a privacy protection that does not exist. Rewritten to state the actual current defaults plainly and to describe a computed-minor-specific default as a recommendation under evaluation, not yet built (docs/legal/_research/age-gating-strategy.md §4.3/§12.1). No other change to §9.3. Full debate record: docs/legal/_research/_history/debate-us.md and debate-global.md, Conflict 6 / Tier 1 item 1 — both independently confirmed the claim false against the live migration SQL, one of the few items in that round resolved definitively rather than merely flagged.
0.1.13	2026-08-16	Australia moved to deferred, found by the age-gating research-completion pass (same day, continued session) — companion fix to Terms of Service v0.1.14. §9.4's Australia paragraph previously stated "bGuru's 16+ gate satisfies natively," which was true of the age NUMBER only and left no indication that Australia was, in fact, unavailable at this version of the Service. Rewrote the paragraph to state plainly that Australia is not available, explain the two open questions that govern (whether bGuru is a covered "age-restricted social media platform" under the Online Safety Act 2021 at all, and whether self-declaration — even bGuru's enforced, honest version — satisfies the eSafety Commissioner's binding "reasonable steps" standard), and state that neither is resolved by the age number matching. Moved Australia from jurisdictions_in_scope to the DEFERRED to v1.1 frontmatter line, and added it to the §9.4 "Forward-looking (deferred markets)" round-up paragraph with a note that, unlike Brazil/India/Canada, its gap is not closed by the planned parental-consent provider integration. No change to the 16-year minimum itself, and no change to any other jurisdiction's treatment. Full research: docs/legal/_research/age-gating-strategy.md §12.5.
0.1.12	2026-08-16	Two corrections surfaced by the age-gating specialist review (see docs/legal/_research/age-gating-strategy.md; the age-gate NUMBER is unchanged, still 16+). New §9.5 Israel subsection: the sole live market previously had no dedicated Children's-data treatment anywhere in §9 (US/UK+EU/rest-of-world all named, Israel was not) — states plainly that the PPL sets no fixed digital-consent age, that bGuru's 16+ floor is its own contractual choice rather than a PPL requirement, and notes the PPA's non-binding draft age-assurance guidance (June 2026). §8.2 and §9.2: added the New York SAFE for Kids Act's actual effective date (not yet in force; final AG rules published 28–29 July 2026; substantive obligations operative 25 January 2027) — the prior text cited "(2024)" without a date in both places, which read as already-binding.
0.1.11	2026-08-10	Corrected §3.1's "Crash + performance data" description to match a same-day product change: the mobile app's Sentry integration was rewritten (PR #512) to stop sending any user identifier at all — no email, display name, account ID, or device ID — rather than the "anonymised user identifier" previously described. This is a narrowing (less data disclosed than before, not more) so no 30-day material-change notice or user re-consent is required under §11 — updated per the non-material-change path (typographical/factual correction). Also removed "anonymised" as the description for this data point: a re-linkable identifier tied to an account would have been pseudonymous, not anonymous, so the old wording was already an imprecise label for what was briefly implemented; since no identifier is sent at all now, the point is moot rather than relabelled. Updated §0 plain-language summary to match. Corrected §3.2 EU/EEA paragraph, which cited "device identifiers in Sentry crash reports" as an example of indirectly-identifying data — no such identifier is sent; reworded to cite the device/crash-context metadata that is sent, and to state plainly that it carries no identifier. Strengthened §4.2 EU/EEA's Art. 6(1)(f) legitimate-interest balancing test: it previously noted the data "does not include directly identifying personal data," which left the possibility of an indirect/pseudonymous identifier open; it now states plainly that no identifier of any kind (direct or indirect) is present and that Sentry's IP-address inference is disabled, which favours the legitimate-interest basis more strongly than the prior wording. No change to §5 (Sentry remains a named sub-processor; see the sub-processor list for the matching correction), §6, or §7 (retention unchanged — still 30 days, Sentry's default). Companion corrections in the same pass: sub-processor list v0.1.10 and Cookie & Ad-Tech Policy v0.1.9.
0.1.10	2026-07-19	Added disclosure of first-party, in-house product analytics (no third-party analytics SDK — no Firebase/GA4, no Mixpanel, no PostHog, no Amplitude). New §3.1 "Product analytics data" category (event name, screen name, timestamp, per-app-launch session id, platform, app version + build number, structured context; linked to your account; server-derived session events collected since 2026-07-19 with history reconstructed back to launch 2026-06-08). Rescoped the §3.1 "Behavioral-tracking data" exclusion to advertising/marketing/profiling tracking specifically, so it no longer contradicts the new product-analytics disclosure. Added a §4.1 lawful-basis table row (legitimate interest, mirroring the existing Sentry treatment) and extended the §4.2 Israel paragraph accordingly. Added a §7 retention row: raw analytics events retained 12 months on an automated rolling purge; aggregated, de-identified statistics retained indefinitely; all deleted immediately on account deletion regardless of the 12-month window. No new sub-processor (the analytics engine is in-house) and no change to §5/§6 (data stays in the same Frankfurt database already covered by the existing sub-processor and international-transfer analysis).
0.1.9	2026-06-08	AdMob SDK removed from MVP codebase (branch chore/remove-admob-mvp). Advertising posture flipped from "NPA ads active at MVP" to "no ads at MVP — planned for v1.1+". Updated: §0 plain-language summary (removed NPA ads description); §3.1 (removed ad-impression data row; IDFA/GAID "NOT collected" row updated); §3.2 jurisdiction advertising-posture paragraphs (EU/UK/IL/US/ROW — all now say "no ads at MVP"); §4.1 lawful-basis table (ad-impression row marked "not applicable at MVP"); §4.2 EU/UK/IL lawful-basis paragraphs (AdMob legitimate-interest analysis removed; forward-reference to v1.1+ added); §5 (AdMob removed from active sub-processors list; note added about v1.1+ re-introduction); §5 CCPA sell/share analysis simplified (no ad SDK = not triggered); §8.2 GPC paragraph updated; §9.3 UK/EU under-18 sections updated (no ads at MVP). Google LLC (AdMob) remains in the inactive sub-processors section of the sub-processor list with a description of the v1.1+ plan.
0.1.8	2026-06-02	Refined the age-restricted ad-treatment description to use generic public wording rather than naming a specific Google SDK flag (§3.1 / §9.3). The substantive behaviour is unchanged. Collapsed the public changelog's pre-launch drafting iterations into a single summary entry for clarity.
0.1.7	2026-06-02	Refined the AdMob category-blocking description (§0) to match what we currently control (Google AdMob console + kill-switch) rather than asserting a contractual commitment not yet in place. Updated Maryland MODPA reference (§9.2) to 'no-behavioral-advertising posture'. Added consent fallback safety commitment in §3.2 EU, §3.2 UK, and §4.2 EU/UK.
0.1.6	2026-06-02	Refined AdMob NPA-mode descriptions to reflect what bGuru configures. Softened six absolute legal conclusions to defensible first-person claims. Added gambling-category advertising prohibition to §0.
0.1.5	2026-06-02	Updated to describe non-personalized advertising via Google AdMob (§0 / §3.1 / §4.1 / §4.2 / §5 / §9.3). Google LLC (AdMob NPA mode) named as active sub-processor.
0.1.4	2026-06-02	Clarified that the no-ads posture applies to this version of the Service; added forward-looking advertising notice.
Pre-launch drafting iterations	2026-05-30 → 2026-06-01	Multiple internal drafting iterations during the pre-launch review period. The substantive provisions described above were drafted, refined, and consolidated through this period.