Privacy Policy — OYLIW (Offload Your Life in Weeks)

Last updated: 2026-07-28 · Version: 2.2 · See the changelog.

The short version

We built this to be honest about time. It would be strange to be dishonest about your data.

Signed out — the default, and the whole product for most people:

Your birthdate never leaves your device. Neither do your labels, milestones, or chapters. They live in your browser's own storage, on your machine. No network request carries them. We do not receive them, we do not store them, and we could not produce them if someone asked us to.
You don't need an account. You never have to make one.

Signed in — only if you choose it:

Signing in is entirely optional and explicitly opt-in. Nothing already on your device is uploaded until you sign in and choose to save.
If you do sign in, we then hold a copy of your grid on our servers, so it survives a cleared browser and follows you to another device. We say this plainly because it is the exact opposite of the promise above, and it applies only to the mode you chose.
By default a saved grid is private. Publishing one at a public link is a separate, deliberate, per-grid action.
Deleting your account deletes the server copy — the grid rows, the session records, and the published links, all of it.

Both modes:

We don't sell or share your data. Not with advertisers, not with data brokers, not with anyone.
We use no tracking cookies and no ad-tech. None. (Signing in uses a strictly-necessary session cookie — that is not a tracking cookie; see section 4.)
We do collect anonymous, privacy-preserving usage statistics — things like "someone created a grid" or "someone finished an export" — with no birthdate, no email, no name.
"Delete my data" really deletes it. One button, in Settings. Signed out, it clears your device. Signed in, it clears your device and hard-deletes your account and everything attached to it.
Under 16? The app works fully on your device, but we don't offer accounts or publishing to under-16s (see section 9).

If that's all you needed, that's genuinely all of it. The rest of this page is the detail, for the people who want it — and for the law, which asks us to be specific.

1. Who we are

Offload Solutions ("we", "us") is the data controller for the personal data described in this policy.


Controller	Offload Solutions
Product	OYLIW — Offload Your Life in Weeks (`oyliw.com`)
Privacy contact	privacy@oyliw.com
Data protection contact	Our Data Protection Officer is reachable at the same address — mark it "DPO".

Our registered postal address, and our EU/UK representative if we are required to appoint one, are available on request at privacy@oyliw.com.

2. The two modes, and what each one means

This is the most important thing on this page, so it gets its own section. Which mode you are in is your choice, and signed out is the default.

2.1 Signed out — nothing leaves your device

When you enter your birthdate, OYLIW does the maths in your browser and draws your grid in your browser. That birthdate — along with every label, milestone, and chapter you add — is saved into IndexedDB, a storage area your browser provides on your own device.

No network request carries it. We do not receive it, we do not store it, and we could not produce it if someone asked us to. This is unchanged from the first version of this policy, and it is still how the product works unless you sign in.

Two consequences worth understanding:

We can't recover it for you. If you clear your browser data, use a different device, or use private browsing, your grid is gone. There is no server copy to restore from. (Signing in is the answer to this, and that is the whole reason accounts exist.)
If you share a grid link from this mode, the grid data is encoded in the part of the URL after the # symbol. By how the web works, browsers never send that part to a server — including ours. So a shared link carries your grid to whoever you send it to without routing it through us. Do bear in mind that the link itself contains your data, so only send it to people you mean to.

2.2 Signed in — we hold a copy, on purpose

If you sign in, you are asking us to keep your grid for you. So we do:

Your grid — the birthdate or birth year it is built from, your labels, milestones, and chapters — is stored on our servers. We make no data-residency promise about where those servers are; see section 7.
Nothing is uploaded retroactively. A grid that was on your device before you signed in stays there and stays yours; it is copied to the server only when you sign in and save it. If you never sign in, nothing is ever uploaded.
By default we store your birth year, not your exact date of birth. The grid is drawn from the exact date on your device; the server only needs the coarse year for everything it does. Storing the exact date on our servers is a separate opt-in you can give and withdraw. This is a deliberate minimisation choice, not an accident of implementation.
Your saved grid is private by default. It is visible to you, signed in. Publishing it to a public link is a separate action you take per grid, and you can revoke it (see section 12).
Signing out does not delete anything; deleting your account does.

2.3 What changes about the core promise

The signed-out promise in §2.1 is not weakened, hedged, or reinterpreted by the existence of accounts. It applies in full, to everyone who does not sign in, which is everyone by default. What is no longer true for signed-in users is the sentence "there is no server copy" — because they asked for one.

3. What data we actually process

What	Where it lives	Do we receive it?
Your birthdate (signed out)	Your device (IndexedDB)	No
Your labels, milestones, chapters (signed out)	Your device (IndexedDB)	No
Your life-expectancy setting (signed out)	Your device (IndexedDB)	No
Your birth year (signed in)	Your device and our database	Yes — you asked us to save it
Your exact birthdate (signed in, opt-in only)	Your device; our database only if you opt in	Only if you opt in — off by default
Your labels, milestones, chapters (signed in)	Your device and our database	Yes — you asked us to save it
Your email address (signed in)	Our database, via your Google account	Yes — it is how we know it's you
A one-way hash of your email (signed in)	Our database	Yes — used as the durable internal identifier instead of the address itself
Session records (signed in)	Our database + a session cookie on your device	Yes — how you stay signed in, and how we can sign you out everywhere. Each record holds the browser you signed in with and a shortened, coarse version of your IP address — enough to spot an intrusion, not enough to pinpoint you
Security audit records (signed in)	Our database	Yes — the event ("signed in", "session revoked"), a timestamp, a coarse IP prefix, and, while your account exists, a link to it. See section 8
Your consent records (signed in)	Our database	Yes — if you turn on exact-date storage, we keep a note of when you did and which version of this policy you saw, because we have to be able to show your consent was real
A flag if the age check turned you away (sign-up)	Our database	Yes — see section 9
Published grid content (only if you publish)	Our database, served at a public link	Yes — that is what publishing means
Anonymous usage events (e.g. "grid created", "export completed")	Our own database — no analytics company is involved	Yes — see section 4
Standard server logs when you load the page (IP address, browser type, timestamp)	Our hosting provider	Yes — short-lived, security/operations only

We do not collect: your name, your location, your contacts, or any advertising identifier. We do not require a name or a date of birth to hold an account — an email address (from your Google sign-in) is the only mandatory item.

We want to know whether the product works: do people who land on the page actually get to a finished grid? Where do they give up? That's it.

What we measure. Anonymous, aggregate product events — a grid was created, a milestone was added, an export completed, an export failed. Where we need a sense of audience, we use coarse age buckets, never your exact age or birthdate.

What we never send. Your birthdate. Your labels. Your email address. Nothing that identifies you personally.

If you have an account, our analytics attaches an internal account identifier — a random UUID we generate — to your events, so that a person using two devices isn't counted as two people. That identifier is not your email, not a hash of your email, and not anything you could be looked up by outside our systems, and event properties remain free of personal data. We have re-assessed our legitimate-interests balancing for this specifically, and we keep that assessment on file — ask us for a summary at privacy@oyliw.com.

Who processes it. We do — nobody else. As of 2026-07-28 there is no third-party analytics company in this product at all. Events are sent to our own server, on the same web address you are already on, and stored in the same database we run for accounts, in a separate area of it that is walled off from account data. There is no analytics vendor to hold your data, no vendor account for us to log into, and no vendor for us to name here.

Why you're not seeing a cookie banner. Consent banners exist because of rules about storing or reading information on your device. Our analytics writes nothing at all to your device: no cookie, no identifier in your browser's storage, nothing. The only identifier involved is a random number that exists in the tab you have open and disappears the moment you close or reload it. Because we genuinely don't store or read anything on your device for analytics, that consent requirement isn't triggered, and showing you a banner would be theatre rather than a real choice.

This used to be less true than it is now, and we fixed it rather than reworded it. Until 2026-07-28 our analytics kept a random identifier in your browser's storage so we could tell a returning visitor from a new one. That is a write to your device, and it sat uncomfortably beside the sentence above. We removed it. The cost is ours: we can no longer measure how many people come back a month later, and we have decided that is the right price for this paragraph being straightforwardly accurate.

And you can simply turn it off. There is a switch in Settings — Anonymous usage counts. Turn it off and nothing is sent and nothing is queued. We also honour Global Privacy Control and Do Not Track signals from your browser automatically, without you having to find the switch. Turning it off costs you nothing: no feature changes, no nag.

The one cookie we do set is a session cookie, and only after you sign in. It exists solely to keep you signed in; it is what the law calls strictly necessary, it carries no tracking function, and it does not require a consent banner either. If you never sign in, you never get it.

Our lawful basis for analytics is legitimate interests (Article 6(1)(f) GDPR): we have a genuine interest in understanding whether our product works, and we pursue it in the least intrusive way we could find. We've written down that assessment and we keep it on file — you can ask us for a summary at privacy@oyliw.com.

You can object. See section 10. And if we ever change this — if we add a tracking cookie, session recording, or any third-party advertising pixel — we will ask for your consent properly, with a real banner, before doing it. That's a commitment, not a formality.

Analytics loads after the page has already drawn, so it never slows down the thing you came for.

5. Lawful bases, in one table

What we process	Why	Lawful basis (GDPR)
Birthdate, labels, milestones — signed out	To draw your grid	None needed from us — it stays on your device; we are not processing it
Account data (email, email hash, sessions)	To give you the account you asked for and keep it secure	Contract (Art. 6(1)(b))
Your grid, stored on our servers — signed in	To provide the save-and-sync service you signed in for	Contract (Art. 6(1)(b))
Exact date of birth on our servers	Not needed for the service; stored only if you want it	Consent (Art. 6(1)(a)) — opt-in, withdrawable, off by default. The coarse birth year remains the default.
Publishing a grid at a public link	To publish the thing you asked to publish	Consent (Art. 6(1)(a)) — per grid, withdrawable by unpublishing
Age check at sign-up (section 9)	To keep under-16s out of accounts and publishing	Legitimate interests (Art. 6(1)(f)) — protecting children, and managing our own legal risk.
*Personal data about someone the grid is about, where that person is not you* — a partner, a parent, a child, someone who has died	Storing and, if you publish, serving the grid you created	Legitimate interests (Art. 6(1)(f)) — yours in keeping the record, ours in operating the service, balanced against that person’s rights. If a grid has been published about you, section 12.1 is written for you.
Security audit records	Detecting and investigating account takeover and abuse	Legitimate interests (Art. 6(1)(f))
Anonymous usage events	To understand and improve the product	Legitimate interests (Art. 6(1)(f))
Server logs	Security, abuse prevention, keeping the site up	Legitimate interests (Art. 6(1)(f))

Do you have to give us any of this? No, not to use the product — signed out, there is nothing to give. If you want an account, an email address (from your sign-in provider) is the one thing we genuinely need; without it there is no account to attach a grid to. Everything else on this page is either generated by using the service or optional and off by default.

A note about sensitive detail, which we would rather raise than let you discover. A milestone or a chapter is free text, and people write real things in it — a diagnosis, a bereavement, a faith, a relationship. Under Art. 9 GDPR that kind of detail is a special category of personal data, and the ordinary contract basis above is not enough on its own to hold it on our servers.

[Placeholder — P2/P3] Payments and live sessions are not covered here because they do not exist. See section 13. The v1.0 placeholders for accounts and public grids are gone from this section because those features are now described above, not deferred.

We do not sell your personal information. We do not share it for cross-context behavioural advertising. We have no advertising relationships at all.

Our service providers ("sub-processors"). There are three. Analytics used to make a fourth; as of 2026-07-28 it does not, because we now run it ourselves:

Provider	Role	What they do	Where	Safeguard
Vercel	Processor	Website hosting and delivery	No commitment — see §7	Data processing agreement
Neon	Processor	The database that stores accounts and saved grids	No commitment — see §7	Data processing agreement; transfers as described in §7
Google	Independent controller for your Google account; recipient for sign-in	Verifies who you are when you choose "Sign in with Google", and tells us your email address and that the sign-in succeeded	United States	Google’s own terms and privacy policy govern your Google account; transfers as described in §7

A note on Google. When you sign in with Google, you are using an account you already have with Google, under Google's own privacy policy, not ours. We receive your email address and confirmation that the sign-in worked. We do not receive your Google password, your contacts, your calendar, or anything else, and we do not ask for access to them. Google will know that you signed in to OYLIW; that is inherent to using a Google sign-in, and it is a reason you might reasonably prefer not to have an account at all — which remains a fully supported way to use this product.

That's the whole list. We keep it current, and we'll update this page when it changes.

We may also disclose information if we're legally required to — a valid court order, for example.

7. Where your data is, and international transfers

We are a Singapore company, and we serve visitors worldwide.

We do not make a data-residency promise. We are not going to tell you that your data is kept in any particular country or region, because we have not committed our providers to one and we would rather say nothing than say something we cannot hold ourselves to. An earlier draft of this policy said our analytics was hosted in the EU; we have withdrawn that claim rather than restate it in weaker words. Withdrawing it does not change what we collect, how little of it there is, or who can see it — every other commitment on this page is unaffected.

Where any provider processes personal data outside a visitor's own jurisdiction — including outside the European Economic Area for visitors covered by the GDPR — we rely on either an adequacy decision or Standard Contractual Clauses, together with an assessment of whether those protections actually hold in that country.

Analytics is no longer a transfer question at all. As of 2026-07-28 usage events are not sent to any third party, in any country — they go to our own server and our own database. Whatever remains unsettled above concerns the account database and the sign-in provider; it does not concern analytics, because there is no analytics recipient left to transfer anything to.

If you are signed out, your grid data isn't transferred anywhere — it's on your device.

8. How long we keep things

Data	How long
Your birthdate, labels, milestones — signed out	Until you delete them. They're on your device, under your control — we hold no copy and no clock runs on our side.
Your saved grid — signed in	For as long as your account exists. Delete the grid, or delete your account, and it goes.
Your account record (email, email hash)	For as long as your account exists. Deleted immediately and permanently on account deletion — not soft-flagged.
Session records	Until the session expires or is revoked, whichever is first; all sessions are revoked and deleted when you delete your account.
Security audit records	While your account exists they are linked to it, because an audit trail you can't tie to an account can't be investigated. On account deletion that link is severed and what remains is de-identified — the event, the timestamp, a coarse IP prefix, and no route back to you. The de-identified remainder is kept no more than 12 months, then purged.
Your analytics record	Events are kept for the period below. If you have an account, the events tagged with your account identifier are deleted in the same operation that deletes your account — not asked for afterwards, not best-effort, not dependent on anyone else. Either the whole deletion happens or none of it does.
Published grid content	Until you unpublish it or delete your account. See section 12 for the honest caveat about copies other people already made.
Anonymous usage events	90 days as individual events, then folded into plain counts (how many grids were created on a given day, and so on) that contain no identifier of any kind. Those counts are kept 24 months, then deleted. Both limits are enforced by a scheduled job in our own code, not by a setting we remember to check.
Server logs	Short-lived — retained only as long as needed for security and operations

Deleting your data. There's a "Delete my data" control in Settings, and it does the right thing for whichever mode you're in:

Signed out: it clears your grid, your labels, and everything else from your browser's storage.
Signed in: it does all of that and hard-deletes your account on our servers — your account record, every grid you saved, every milestone and chapter, every session, and every published link, which stops working immediately. This is a real deletion, not a flag that hides the row.

Either way it's immediate and permanent — we'll tell you that plainly before you confirm, because it can't be undone.

9. Children and young people

OYLIW is a reflective tool about time, and some of it is heavy. Our rule is simple and deliberately cautious:

We do not offer accounts, publishing, or purchases to anyone under 16.

The on-device app keeps working for them, fully and unchanged. A young person can enter a birthdate, build a grid, add milestones, export an image, and share a link — all of it, on their device, with nothing reaching us. What they cannot do is create an account, save a grid to our servers, or publish one at a public link.

How we check. At sign-up, at any publish, and at any purchase, we work out an age on our servers — never only in the browser, because a client-side check can be bypassed. We do it from the birth year alone, and we assume the least favourable case: if you could still be 15 given that year, we treat you as 15. This deliberately errs toward turning people away, and it means we never need your exact date of birth to make the call.

Why 16, and not 13? Different countries set the "digital age of consent" anywhere between 13 and 16, and the US sets a separate rule at 13. Rather than guess at your location to apply a different rule to different people — which would mean tracking where you are, a privacy cost in itself — we apply the strictest threshold to everyone. It means we turn away some 13-to-15-year-olds who could legally sign up in their country. We think that's the right trade.

It is an automated check, and we'll say so. No person looks at it; a rule runs on our servers and either lets the sign-up through or doesn't. Because it errs deliberately toward turning people away, it will sometimes turn away an adult — a mistyped year is all it takes. If that happens to you, write to privacy@oyliw.com and a real person will look at it and put it right. You have a right to that human review and to contest the outcome, and we'd rather offer it than make you ask for it. We also keep a note that the check blocked a sign-up, so the same account can't simply retry with a different year.

If you believe a child has provided us personal data, write to privacy@oyliw.com and we'll delete it.

10. Your rights

Under the GDPR, UK GDPR, and similar laws, you have the right to:

Right	What it means
Access	Ask what personal data we hold about you and get a copy
Portability	Receive it in a structured, machine-readable format
Rectification	Have inaccurate data corrected
Erasure	Have your data deleted ("right to be forgotten")
Restriction	Ask us to pause processing while a dispute is resolved
Objection	Object to processing based on legitimate interests — including our analytics
Withdraw consent	Where we rely on consent — storing your exact birthdate, publishing a grid — withdraw it at any time, without it affecting what was lawful beforehand

If you're in California, you also have the right to know, delete, correct, and opt out of sale/sharing — and to not be discriminated against for exercising them. As stated in section 6, we do not sell or share your personal information, so there is nothing to opt out of. We have not sold or shared personal information in the preceding twelve months, and we do not knowingly sell or share the personal information of anyone under 16. You can also send an authorised agent to make a request for you; we'll ask for proof that you authorised them, and for enough from you to be confident the request is really yours.

How to exercise any of these: email privacy@oyliw.com. We'll respond within one month (GDPR) or 45 days (California). If a request is genuinely complex we may extend that, and we'll tell you why before we do.

A caveat we'd rather state up front than hide: if you are signed out, the most direct route isn't us — it's the "Delete my data" button in Settings. We can't access, export, or delete what's on your device, because we never had it. If you have an account, that same button handles the server side too, and you can of course email us instead.

Complaints. If you think we've handled your data badly, please tell us first — we'd like the chance to fix it. You also have the right to complain to your data protection authority. In the EU, that's the supervisory authority in your country (list here). In the UK, it's the Information Commissioner's Office.

11. How we protect what we hold

HTTPS everywhere, so traffic between you and us is encrypted.
A strict Content Security Policy — the page is only allowed to load resources from us. No third-party scripts, no font CDNs, no trackers riding along.
Self-hosted fonts, so no external provider learns you visited.
No passwords. We never hold one, so we can never leak one. Sign-in goes through Google, which you already secure.
Session cookies are httpOnly and Secure, so page scripts cannot read them, and sessions can be revoked instantly on our side rather than remaining valid until they expire.
Every read and write of a saved grid is authorised on the server against who owns it. The browser is never trusted to say which grid you're allowed to see.
Analytics runs on our own infrastructure, in a separate area of the database with its own restricted credentials that can add a usage count and read nothing — not your account, not your grid, not even the counts it just wrote. There is no third-party analytics code in the page at all.
Data minimisation as a primary control. We store a birth year rather than an exact date by default, and a hash of your email rather than the address wherever the flow allows it. The less we hold, the less there is to lose.

No system is perfectly secure. If you are signed out, a breach of our servers would not expose your birthdate, because we would not hold it. If you have an account, we hold your email address and your saved grid, and we would tell you without delay if they were exposed — we won't repeat the older version's line that there is nothing there to breach, because for account holders that is no longer true.

12. Published grids

Publishing is off by default, per grid, and reversible. Some honest detail about what it means:

A published grid is public. Anyone with the link can open it. It is read-only — visitors cannot change it — but it is not secret, and you should assume a link can be forwarded.
We ask search engines not to index published grids, so they shouldn't turn up in search results. That is a request that well-behaved crawlers honour; it is not a technical guarantee, and we won't pretend otherwise.
You can unpublish at any time, and the link stops working immediately. Deleting your account unpublishes everything.
What we cannot undo is a copy someone already made — a screenshot, a saved image, an archive service that already crawled the page. Unpublishing stops us serving it; it cannot reach into someone else's device.
Grids about other people. The tool lets you build a grid about a child, a parent, someone who has died. Publishing such a grid means publishing information about a person who is not you and who did not choose this. Please think hard before you do, and please don't publish one about a living person who wouldn't want it. If someone finds a published grid about themselves and wants it gone, write to privacy@oyliw.com — we will act on that.

12.1 If a grid has been published about you

This part is for someone who has never used OYLIW and has no reason to. If you have found a published grid that is about you, you are a data subject and we are holding personal data about you, even though you never gave it to us. That gives you rights, and this is where we tell you about them, because the law requires us to and because you would otherwise have no way of knowing.

Where it came from. Not from you. Another user typed it in, on their own device, and chose to publish it. We did not collect it from any public source, buy it, or infer it.
What we hold. Whatever they entered: typically a birth year or date, a label naming you, and any milestones or chapters they wrote. We hold no other record of you.
Why we hold it. To serve the page they published. Our basis is our and their legitimate interests in operating and using the service (Art. 6(1)(f)).
We did not write to you, and here is the honest reason. Art. 14 GDPR normally requires a controller to tell you directly when it obtains your data from someone else. We have no way to contact you — we hold no address for you, and finding one would mean going looking for you, which is worse than not writing. We rely on Art. 14(5)(b) — that direct notice is impossible or a disproportionate effort — and this section is the compensating measure that provision requires: the information, made public, where a person in your position would look.
What you can do. Object to the processing, ask for a copy of what we hold, ask us to correct it, or ask us to erase it. Write to privacy@oyliw.com. You do not need a lawyer, a legal form, or a reason we find persuasive. In practice, for a living person who objects to a grid about themselves, the answer is that we unpublish it. You can also complain to your data protection authority (section 10).

13. Features that still don't exist

These sections will be written when and only when the corresponding features ship. We're listing them so you can see what's coming and so this page grows honestly rather than being quietly rewritten.

[Placeholder — P1/P3] Payments. Stripe as our payment processor, what billing data we hold, and how long tax law requires us to keep it.
[Placeholder — P2/P3] Live sessions. Guest participation, optional display names, how long guest contributions are kept, and what happens to them when a session ends.

14. Changes to this policy

If we change this policy materially, we'll update the Last updated date and note what changed below. For significant changes — especially any change to how we use analytics, or to what we store on our servers — we'll tell you in the product before the change takes effect, not after.

The move from v1.0 to v2.0 is exactly such a change, and it gets that treatment: an in-product notice, shown before accounts go live, explaining what is changing and that the signed-out mode is unaffected.

15. Version history

Version	Date	Change
2.2	2026-07-28	The analytics processor is gone. We stopped using a third-party analytics company and now collect the same anonymous usage events on our own server and store them in our own database. §3: the analytics row names our own database instead of a vendor. §4 rewritten: no third-party processor; the "no banner" explanation is now straightforwardly true rather than arguable, because the identifier that used to be written to your browser's storage has been removed — and the section says so, along with what that costs us. A new opt-out switch in Settings is described, and Global Privacy Control / Do Not Track are honoured automatically. §6: the sub-processor table drops from four rows to three. §7: analytics is no longer described as an international transfer, because it is no longer a transfer — and no region claim is reinstated anywhere. §8: the `[TBD]` on erasing the analytics profile is replaced by a real commitment (deleted in the same operation as the account), and the vendor-configured retention row is replaced by 90 days of events / 24 months of identifier-free counts, both enforced in our own code. §11: added the isolation control for the analytics store. Nothing about what we measure changed — the list of events is identical to the one this policy has always described.
2.0-r2	2026-07-27	EU data-residency claim withdrawn entirely, product-wide (internal ref: legal-and-compliance-spec C3 / ADR-L08 — OYLIW is a Singapore company and no region is committed for any provider). §7 rewritten: the "our analytics is EU-hosted" statement is removed, not reworded, and no substitute region is claimed; the transfer mechanism per provider is flagged as an open item with a named owner rather than filled with reassuring language. §6: region column now reads "no commitment" for PostHog, Vercel and Neon; the former "EU-hosted" safeguard for PostHog is replaced by a `[TBD]` transfer mechanism. §3 and §4: "EU region" / "EU Cloud" removed from the analytics rows. Short version: the "It's hosted in the EU" sentence is gone. The DPIA's C-1 region condition closes by this withdrawal; its transfer-safeguard half stays open. Nothing about what we collect, how long we keep it, or who receives it changed in this revision.
2.0-r1	2026-07-27	Compliance review pass. §3: disclosed the browser string and coarse IP prefix in session and audit records, the exact-DOB consent record, and the age-block flag. §5: replaced the age-gate's "legal obligation" characterisation with legitimate interests (Art. 6(1)(c) requires Union or Member State law; none obliges age verification here); added a row for personal data about third-party grid subjects, flagged as an open basis with no LIA on file; added the Art. 13(2)(e) line and an Art. 9 note. §6: flagged the missing email-delivery recipient if magic-link ships. §8: corrected the audit-record row, which described records as de-identified throughout when they are identified for the life of the account; added a `[TBD]` analytics-profile row. §9: disclosed the age check as an automated decision and added a human-review route. §10: added the CCPA twelve-month and under-16 no-sale statements and the authorised-agent route. Added §12.1, an Art. 14 notice written to third parties who are the subject of a published grid. Four new open blockers recorded at the head of the document.
2.0	2026-07-27	Accounts and hosted grids. Restructured around two modes (signed out / signed in). Added: account-data and server-storage rows to §3; contract and consent lawful bases to §5; Neon and Google to the sub-processor table in §6; account, session, and audit-record retention to §8; the server-side under-16 age check to §9; §12 on published grids. Rewrote §2 and §11 so that no unqualified claim that we hold no copy survives — where the phrase remains (§2.1, §8), it is explicitly scoped to signed-out use, where it is still true. Filled the former §5 and §12 accounts/public-grid placeholders. Signed-out promise retained verbatim and unweakened. Not yet published — pending counsel review and DPO sign-off.
1.0	2026-07-23	Initial Phase 0 policy. Scope: on-device solo grid + cookieless EU analytics. No accounts, payments, public grids, or live sessions.

Questions? privacy@oyliw.com — a real address, read by a real person.