Skip to content
Back to OYLIW

Privacy Policy — OYLIW (Offload Your Life in Weeks)

Last updated: 2026-08-16 · Version: 3.5 · 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:

Signed in — only if you choose it:

Both modes:

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 Foundry ("we", "us") is the data controller for the personal data described in this policy.
Controller Offload Foundry
Product OYLIW — Offload Your Life in Weeks (oyliw.com)
Privacy contact privacy@notify.offloadfoundry.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@notify.offloadfoundry.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:

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:

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 exact birthdate (signed in) Your device and our database Yes — you asked us to save your grid, and the grid is drawn from it
Your exact milestone and chapter dates (signed in) Your device and our database Yes — they are the content of the grid you saved
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
Your username (signed in) Our database Yes — you choose it, so that you can see which account you're signed into. It is not taken from Google, and nobody else sees it
A one-way hash of your email (signed in) Our database Yes — used as the durable internal identifier instead of the address itself
Your IP address and browser signals, at the anti-spam check (feedback page only) Cloudflare — see §6. Nowhere on our side No. The check happens between your browser and Cloudflare. We receive the result, not the signals, and we write none of it down
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 — when you publish a grid we keep a note of when you did it and which version of this policy you saw, because we have to be able to show your consent was real. (This row used to describe a switch for turning on exact-date storage. There is no such switch: dates are stored exactly, always, under contract rather than consent — see section 2.2 and section 5. Publishing is the one thing here we still rely on consent for.)
Published grid content (only if you publish) Our database, served at a public link Yes — that is what publishing means
What we send to write a story (only if you ask for one) — the labels you picked, word for word, and your age in whole years at each one Sent to Anthropic; not stored by us a second time Yes — we assemble it and send it. What is deliberately not in it: your birthdate, every date on your grid, your grid's name, the label naming who the grid is about, your name, your email address, and every id we hold. The text we actually send is thrown away once the request is made; we keep no copy of it. See section 6
The generated story itself (only if you asked for one) — the text, plus which entries it was written from and which model wrote it Our database Yes — so that reloading the page does not rewrite it, and so a story you liked is still there. Kept until you delete it, delete the grid it belongs to, delete your account, or withdraw permission — there is no expiry date; see section 8. It is never attached to a published grid (section 12)
A record that you gave permission to send it (only if you asked for one) Our database, as a security audit record Yes — the time, and an identifier for the exact wording you were shown. Not the story, not the labels. See section 5
Your diary entries (only if you write one) — the title and text you type, the day, week, month or year it is about, and your time zone Our database Yes — that is what saving an entry means. ⚠️ It is not end-to-end encrypted, and we will not call it that. It is encrypted in transit and at rest like everything else we hold, but our servers read the plaintext — search would not work otherwise, and neither would reflections. We can read your diary. We don't, but we could, and you should decide with that in mind
Your diary check-ins (optional, per entry) — the feeling words you press, the self-care words you press, and an energy number from 1 to 5 Our database Yes. Every one is optional and every one is something you chose from a fixed list. A blank is never filled in for you: we do not guess a mood from what you wrote, and a day with nothing on it means you did not say — not that you felt nothing
What we send to write a reflection (only if you ask for one) — the full text of the entries you selected, their dates and their check-ins Sent to Anthropic; not stored by us a second time Yes — we assemble it and send it. What is deliberately not in it: your birthdate, any date from your grid, any other grid, your grid's name, your username, your email address, and every entry you did not select. ⚠️ What is in it is whatever you wrote. If you typed a person's name, a place, a date of birth or a diagnosis into an entry you selected, that goes — it is your writing and we do not edit it. Your grid's date of birth is never added and never inferred from anything in an entry. See section 6
A reflection we generated (only if you asked for one) — the summary, the observations, the short excerpts of your own writing it quotes, and which model and prompt version made it Our database Yes — so it is still there when you come back. Kept until you delete it, and it goes automatically if you delete an entry it quotes, delete all your diary data, withdraw permission, or delete your account. See section 8
A record that you gave permission for diary processing (only if you asked for a reflection) Our database Yes — the time and which version of the wording you saw. ⚠️ This is a separate permission from the one for life stories, and always was. Agreeing to have grid labels sent never authorised sending diary text, and we do not treat an old story permission as covering this
A count of the reflections you have used this week Our database Yes — a user id, a timestamp and nothing else. ⚠️ It survives "Delete all diary data", and that is deliberate: without it, deleting your diary would reset your weekly allowance and the limit would mean nothing. It says that a reflection was used, never what it said. It is deleted with your account. See section 8
A feedback message (only if you send one) — what you typed, the email address you enter, whether you called it a bug or a suggestion, which plan you are on, and the build number Sent to a third-party messaging platform (section 6); not stored by us at all Yes — we relay it. What is deliberately not in it: your birthdate, any date on your grid, your grid's name or its contents, any label, milestone or chapter, any story, your username, your account's email address, and every id we hold. We do not read the email address off your account even when you are signed in — the only address that leaves is the one you typed. We keep no copy of any of it; see section 8
Anonymous usage events (e.g. "grid created", "export completed") Our own database — no analytics company is involved Yes — see section 4
Your browser's identification string, its version, your operating system, your device type and your country — attached to those usage events Our own database Yes — see section 4. Every one of these is read from information your browser sends to every website automatically; the country is worked out from your network address by our hosting platform, and your address itself is never stored
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.

About the username. When you first sign in we ask you to choose a username. It exists for one reason: so the app can show you which account your grid is saving to. It is a name you make up, not one we read from your Google profile — we deliberately did not ask Google for your name or your profile picture, because we would then hold data we don't need. Your initials in the app are drawn from the username itself, on your own device; no picture is fetched from anywhere. You can change it, at most once every 7 days.

4. Analytics — what we measure and why there's no cookie banner

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.

And, since 3 August 2026, some technical context about the request. When your browser asks any website for a page it announces some things about itself, without being asked and without us running any code on your device. We now keep what it announced, alongside the event:

Why. So that "10% of exports are failing" can become "10% of exports are failing, and every one of them is Safari 17 on iOS" — which is the difference between knowing something is broken and being able to fix it. We could not answer that question at all before.

What we never send, and still don't. Your birthdate. Your labels. Your email address. Your username. Nothing that identifies you personally.

What we do not store, stated as plainly as we can:

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@notify.offloadfoundry.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@notify.offloadfoundry.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, and exact milestone and chapter dates, on our servers They are the grid you asked us to save; the service cannot return the grid you made without them Contract (Art. 6(1)(b)) — the same basis as the rest of your saved grid. Signing out, or not signing in, is how you decline this processing.
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
Sending your labels and whole-year ages to a language model to write a life story To write the story you asked for Consent (Art. 6(1)(a)) for the sending, and — because those labels can carry health, faith, sex life or belief — explicit consent under Art. 9(2)(a) for that. Asked for in its own dialog, every time, before anything is sent. Withdrawable, and withdrawing deletes the stories
Your diary entries, stored on our servers To provide the diary you signed in to write Contract (Art. 6(1)(b)) for the storage. ⚠️ The Art. 9 problem here is sharper than it is for a grid, and we are not going to pretend otherwise. A diary is where people write about illness, pregnancy loss, faith, sex life and abuse — not somewhere it occasionally surfaces. The owner's position is that Art. 6(1)(b) covers the storage. The Art. 9(2) condition for storing that text on our servers is not settled, exactly as it is not settled for grid content.
Sending the diary entries you selected to a language model to write a reflection To write the reflection you asked for Consent (Art. 6(1)(a)) for the sending, and — because diary text routinely carries health, sex life, faith and belief — explicit consent under Art. 9(2)(a) for that. ⚠️ A separate permission from the life-story one, asked for in its own screen naming what is sent and who receives it. Withdrawable, and withdrawing deletes every reflection immediately and leaves every entry untouched
Keeping a reflection we generated for you So it is still there when you come back, and so a reload does not regenerate it Contract (Art. 6(1)(b)). Kept until you delete it — and destroyed automatically when an entry it quotes is deleted, because short excerpts of your writing must not outlive the writing
Counting the reflections you have used this week To enforce the weekly allowance on a paid plan Contract (Art. 6(1)(b)) — it is how the thing you bought is measured. It holds no content, and it survives deleting your diary so that deleting cannot reset the count
Keeping the story we wrote for you So a reload does not rewrite it, and so it is still there when you come back Contract (Art. 6(1)(b)). Not time-bounded — it is kept until you or your account are gone; see section 8
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. 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.

The one place where we have settled it, and how. For the written life story — and only for that — the condition we rely on is Art. 9(2)(a), explicit consent, and here is exactly what that means in the product rather than in the abstract. Before anything is sent, you are shown a dialog that states, all on one screen and none of it hidden behind a "read more": what is sent (the labels you picked and your age in whole years), what is not (your birthdate and every date on the grid), who receives it, by name, that they may keep it and that we have no agreement with them saying otherwise, that the result may be wrong about your own life, and that refusing changes nothing else about the product. Nothing is sent until you press the accept button. We record that you accepted, when, and an identifier for the exact wording you were shown — not the wording again, and not what you wrote — so that if we ever change that wording, your consent stays attached to the words you actually read. There is a "withdraw permission" control on the same screen: it deletes every story we hold for you, on every grid, immediately. That control matters more than it used to: since we no longer delete stories on a timer (section 8), withdrawing permission — or deleting the story, the grid, or your account — is the only thing that removes one.

[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.

6. Who we share data with

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 six, and the sixth is new: Cloudflare, which runs the anti-spam check on the feedback form. Analytics used to be on this list too; as of 2026-07-28 it is 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
Anthropic Processor Runs the language model that writes a life story, only when you ask for one. Receives the labels you picked and your age in whole years at each one — no birthdate, no dates, no name, no email, no ids Not stated. Anthropic does not name a processing region in the terms we are on, and we have not asked them to. Assume the United States Anthropic's published data processing terms, which include the 2021 EU Standard Contractual Clauses (Modules 2 and 3) and UK and Swiss addenda. We accepted those terms by using the service; we did not negotiate them and there is no separately signed agreement. Their published commercial terms say they do not train models on what customers send. What we do not have is a term stopping them keeping it — zero retention is something they offer to larger customers who ask, and we have not asked. We would rather tell you that than describe an assurance we do not hold. This is the single weakest safeguard on this page, and it applies to nothing except a story you deliberately asked us to write
A third-party messaging platform Processor Receives a feedback message you send us, and the email address you provide with it, so the maker can read it and reply. Only when you use the feedback form — nothing is sent unless you write something and press send Not stated. We have not committed them to a region and have not asked. Assume the United States The platform's published terms, accepted as offered. ⚠️ There is no negotiated data processing agreement and no separately signed agreement of any kind, on the same footing as the row above — and unlike that row, what reaches them includes an email address you typed, which identifies you directly. We do not store the message or the address ourselves at all (§8); their copy is the only copy
Cloudflare Processor Runs the anti-spam check on the feedback form — the box that confirms you are a person before a message is sent. Receives your IP address and technical signals about your browser. Only on the feedback page. It is the only page in this product that loads anything from another company Not stated. We have not committed them to a region and have not asked. Assume the United States Cloudflare's published data processing addendum, which includes the 2021 EU Standard Contractual Clauses, accepted as offered. They publish that the check does not use cookies and is not used to build advertising profiles. We have not negotiated the terms, on the same footing as the two rows above

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.

A note on Anthropic, and on why this row reads worse than the others. The three rows above it are companies that hold your data because the product cannot run without them — the site has to be served, the database has to exist, the sign-in has to be verified. This one is different: it exists only because you asked for a story, it receives something you wrote about your own life, and it is the only recipient on this page we have no negotiated agreement with. A larger company would have signed one before shipping this. We did not, and rather than describe an ordinary vendor relationship in language that implies we did, the safeguard column says what is actually true. If that is not a trade you want to make, do not ask for a story — nothing else in the product changes, and the option is off until you accept a dialog that says the same thing this paragraph does.

A note on the messaging platform, and on why we do not name it. The law asks us to tell you the recipients or the categories of recipients of your data, and a category satisfies it. We name the other four because we chose to, not because we had to; here we have chosen not to. It is a tool the maker reads messages in, the same way an email inbox would be, and the name of it tells you nothing you can act on — what you can act on is what it receives, which is written in full in the row above. Two things about that row are worth reading twice. The email address is required, because a report we cannot reply to is a report we can only half act on — and it goes to the platform, not into our database. And the message is whatever you type, so do not type anything into it you would not want held by a company we have no agreement with. If that is not a trade you want to make, do not use the form; nothing else in the product depends on it, and there is a plain address at the bottom of this page that reaches the same person.

A note on the anti-spam check, and where it runs. Every other page in this product loads nothing from anyone but us — that is the strict policy described in section 11, and it is unchanged everywhere except one page. The feedback page is the exception, and it is a deliberate one: the form sends a message to a person, an open form gets flooded, and the alternatives we tried first — hidden traps, rate limits, blocking known robots — do not stop someone using a real browser. The check is the only measure that costs a sender something per attempt. What it costs you is this: on that page, and only that page, Cloudflare sees your IP address and some technical signals from your browser. It does not see your message, your email address, your birthdate, or anything on your grid — the check finishes before any of that is sent, and what we send Cloudflare is one short code the check produced, nothing else. If you would rather not, do not use the form; the plain address at the foot of this page reaches the same person, and nothing else in the product goes near this.

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. An earlier draft of this policy said our analytics was hosted in the EU; we have withdrawn that claim. 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.

The language model is a transfer, and a new one. If you ask for a story, the labels you picked leave for a United States company. The mechanism we rely on is the Standard Contractual Clauses in Anthropic's published data processing terms, which we accepted rather than negotiated. We have not carried out our own assessment of whether those protections hold in practice, which is a thing a controller our size is expected to do and a thing we have not done. It is stated here because section 6 states it, and the consent dialog states it before anything is sent.

The feedback form is a transfer too, on the same terms and with the same gap. If you send feedback, what you wrote and the email address you typed leave for a third-party messaging platform, on that platform's own published terms, accepted as offered and not negotiated. No region is claimed for it, because we have not committed them to one — the same position this section takes for every other provider. We have not carried out our own assessment of whether those protections hold in practice, and this one carries a direct identifier you supplied, which is why it is stated separately.

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.
A life story we wrote for you Until you delete it. There is no expiry and no scheduled job that removes it — we used to delete these after 90 days and we no longer do, because a story is something you made on a grid you keep, and the allowance means "just write it again" is not free. Four things delete one, all of them immediate and all of them yours: deleting the story, deleting the grid it belongs to, deleting your account, or withdrawing permission (which deletes every story on every grid at once). ⚠️ Said plainly, because it is the cost of the change: if you do none of those, we hold the text indefinitely. What Anthropic does with what we sent them is governed by their terms and not by ours; see section 6.
Your diary entries Until you delete them. No expiry, no sweep. Four things remove them and all four are yours: deleting the entry, "Delete all diary data", deleting your account, or asking us at the address below. ⚠️ Withdrawing permission for reflections does not delete your diary — it deletes the reflections and leaves every word you wrote, because they are two different things and we will not conflate them
A reflection we generated Until you delete it — and it also goes on its own in four cases, because it quotes your writing: you delete an entry it quotes (the excerpts cannot outlive the entry), you delete all diary data, you withdraw permission, or you delete your account. What Anthropic does with what we sent is governed by their terms and not ours; see section 6
The count of reflections used this week ⚠️ The one thing that survives deleting your diary. Kept until that week's allowance resets, stripped to a user id and a timestamp with no link to any request or any entry. It exists so that deleting and re-writing cannot buy more reflections. Deleting your account deletes it too — there is no allowance left to protect at that point
The record that you gave permission Treated as a security audit record — kept while your account exists, then de-identified and purged with the rest of them (the row above). It has to outlive the story: it is the evidence that the story was allowed.
A feedback message you sent us — and the email address you gave with it ⚠️ This one has no answer we can give you, because we never hold it. It is relayed straight to the messaging platform in section 6 and is not written to our database at any point — there is no row to delete, no sweep to run, and deleting your account does not reach it, because there is nothing of it on our side to reach. The platform's copy is the only copy, kept under their terms and not ours, and the maker reads it there. If you want a message you sent taken down, write to the address at the foot of this page and it will be deleted by hand.
What the anti-spam check saw Nothing on our side, for no time at all — we never receive it. Cloudflare holds what it holds under its own terms; they publish a short retention period for it. We keep only the fact that a message was relayed, which is to say nothing at all, because we do not keep that either.
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.
Your browser's identification string (the technical context in section 4) 90 days, and not one day longer. This one is deliberately different from everything above it. When the 90 days are up and the events are folded into plain counts, the browser family, version, operating system, device type and country carry over into those counts — but the full identification string does not. It is deleted and there is nowhere else for it to survive, because it is not part of what we keep long-term. That asymmetry is on purpose: the shorter life is the safeguard.
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:

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

Two limits on "immediate", stated rather than buried.

Downloading your diary. There is a download on the diary page, in two formats — JSON for moving it somewhere else, Markdown for reading. It contains your entries, your check-ins and any reflections you kept. It is generated for your session and handed to your browser; there is no link, nothing is published, and nothing passes through anyone else. It works after you cancel a paid plan, because taking your own writing with you is not a feature we would charge for.

9. Children and young people

OYLIW is a reflective tool about time, and some of it is heavy — but nothing in it is unsuitable for a younger person. There is no minimum age, and we do not turn anyone away on the basis of their age. We previously refused accounts to under-16s; we don't any more, and no age check runs anywhere in the product.

What that means in practice. Everyone gets the same product on the same terms: the grid works entirely on your device whether or not you sign in, an account is optional, and signing in only adds a saved copy of the grid you already made.

What protects a younger user is what protects everyone. Signed out — the default — nothing about them reaches us at all. We show no advertising and build no profiles. Grids are private until you publish one, and published grids are never indexed by search engines. Our analytics is anonymous and cookieless, and carries no birthdate or age.

If you are a parent or guardian and you'd like us to delete a child's account or the data attached to it, write to privacy@notify.offloadfoundry.com and we will — you don't need to prove anything beyond enough for us to find the account.

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 — publishing a grid — withdraw it at any time, without it affecting what was lawful beforehand. Unpublishing is how you do it, and it takes effect immediately. (Storing your exact birthdate is no longer a consent item: it is part of the grid we hold under our contract with you, and the way to decline it is to use the service signed out.)

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 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@notify.offloadfoundry.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.

One caveat: 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.

Your diary, specifically. Three separate controls, because they are three different decisions: download it (JSON or Markdown, on the diary page, and it keeps working after you cancel a paid plan); withdraw permission for reflections, which deletes every reflection and leaves every entry; and "Delete all diary data", which removes every entry, check-in and reflection while keeping your account. You can also delete a single entry or a single reflection. Deleting an entry destroys the excerpts any reflection quoted from it, automatically and in the same operation.

11. How we protect what we hold

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, the username you chose, 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:

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.

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.

Written life stories used to be one of these and are not any more. They are described above — in sections 3, 5, 6 and 8 — because the feature now exists. This is what we meant by the paragraph above.

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
3.6 2026-09-09 A diary, and the first time we store writing whose whole purpose is to be private. §3 gains five rows: your entries, your optional check-ins, what we send to write a reflection, the reflection itself, and a content-free count of reflections used this week. ⚠️ The sentence worth reading is that a diary is not end-to-end encrypted and we will not call it that — it is encrypted in transit and at rest, and our servers read the plaintext, because search and reflections do not work otherwise. We can read your diary. We don't, but we could, and §3 says so where you decide. §5: storage on contract (Art. 6(1)(b)), sending selected entries to Anthropic on consent and explicit consent under Art. 9(2)(a) — a separate permission from the life-story one, which never authorised this. ⚠️ The Art. 9 condition for storing diary text is recorded as unanswered, on the same footing as the grid-content gap, and it is sharper here because sensitivity is the point of the feature rather than incidental to it. §8: entries and reflections are kept until you delete them; a reflection is destroyed automatically when an entry it quotes is deleted, because excerpts must not outlive the writing; withdrawing permission deletes every reflection and leaves every entry, because they are different things. Two limits on "immediate" are now stated rather than buried: backups roll off on their own schedule, and deleting a reflection does not reach into Anthropic — we hold no term letting us compel that. New: a download in JSON and Markdown, and a "Delete all diary data" separate from deleting your account. ⚠️ One thing survives that deletion and the confirmation says so first: a count of reflections used this week, a user id and a timestamp with no link to anything, so that deleting and re-writing cannot buy more. What did not change: your birthdate still never leaves your device, your grid's date of birth is never added to what we send and never inferred from an entry, and nothing about the diary is reachable without an account. ⚠️ What you type is what we send — a name, a place or a date you wrote into an entry you selected goes to the model, because it is your writing and we do not edit it.
3.5 2026-08-16 A sixth sub-processor, and the first third-party code this product has ever loaded in a page. The feedback form now carries an anti-spam check run by Cloudflare. If you open that page, Cloudflare receives your IP address and technical signals from your browser — not your message, not your email address, and nothing from your grid, because the check finishes before any of that is sent. §6 gains a sixth row, named rather than categorised, and the sentence "There are five" becomes "There are six". §3 gains a row saying the signals go to Cloudflare and not to us. §8 says we keep none of it, because we never receive it. ⚠️ §11 changed, and it is the change worth reading. The strict policy that let the page load resources from nobody but us was a promise on this page; it now carries one exception, on one address — the feedback page — and §11 states it plainly instead of quietly widening the old sentence. Every other page is unchanged: the landing page, your grid, the export and every account page still load nothing from anyone else. What did not change: your birthdate still never leaves your device, no grid content goes anywhere near this, the form is still optional, and the plain email address at the foot of this page still reaches the same person with no check in front of it.
3.4 2026-08-16 Editorial only — nothing about what we collect, why, who receives it, or how long we keep it changes. Four phrases in which the policy commented on its own candour rather than telling you something (§5's "which we would rather raise than let you discover", §7's "we would rather say nothing than say something we cannot hold ourselves to" and "rather than restate it in weaker words", §10's "a caveat we'd rather state up front than hide") are cut or shortened. The withdrawn data-residency claim stays withdrawn, the missing transfer assessments stay stated as gaps, and every lawful basis, retention period and recipient row is unchanged.
3.3 2026-08-16 A fifth sub-processor, and the first recipient that gets an email address you typed on purpose. The product now has a feedback form. If you use it, what you wrote and an email address you must supply are relayed to a third-party messaging platform so the maker can read it and reply. §6 gains a fifth row and the sentence "There are four" becomes "There are five". ⚠️ That row does not name the company, and that is a decision rather than an oversight — the law asks for the recipients or the categories of recipients, we have chosen the category, and §6 says so out loud along with what the row does tell you: what it receives, that there is no negotiated agreement, and that no region is claimed. §3: a new row listing exactly what leaves — your message, your typed address, bug-or-suggestion, your plan, the build number — and the longer list of what deliberately does not: your birthdate, every date on your grid, the grid's name and contents, every label, milestone, chapter and story, your username, your account's email address, and every id we hold. We do not read the address off your account even when you are signed in. §7: a new transfer, on published terms accepted as offered, with no assessment of our own — stated as the gap it is, as the language-model row already is. §8: ⚠️ the retention row for this one says we hold it for no time at all, because we never write it down. It is relayed and forgotten; the platform's copy is the only copy, kept under their terms, and deleting your account does not reach it because there is nothing on our side to reach — if you want a message removed, the address at the foot of this page reaches a person who will do it by hand. What did not change: your birthdate still never leaves your device, no grid content of any kind is in a feedback message, and the form is optional — nothing else in the product depends on it, and the same person can be reached at the plain address instead.
3.2 2026-08-11 A grid's name is now shown on its public page. Grids have an optional label so you can tell yours apart on your grids list. If you publish a grid, that label is now shown to visitors — §12 gains a bullet saying so. It is free text you typed, so it says whatever you put in it: call a grid "Mum" and visitors see "Mum". Leave it unnamed and the public page shows no label at all, and you can change or clear it at any time with the page following immediately. Nothing else about what a published grid exposes changed, and nothing new is collected — the label has existed since August 3rd and was previously visible only to you. The publish confirmation you must accept before a link is created is word for word the one you saw before; it names the dates and the birthdate a visitor will see, and it was deliberately not rewritten, because we would rather change a published policy than quietly re-word a consent screen.
3.1 2026-08-11 We stopped deleting your written life stories after 90 days. They are now kept until you delete them — and this is a change that gives you more and protects you less, so it is written both ways round. What you gain: a story you asked for is still there next year, which matters because the allowance is three stories and one every 30 days after that, so "just write it again" costs you something real. What you lose: the text sits in our database indefinitely unless you act, where it used to disappear on its own within three months. §3, §5 and §8 all now say kept until you delete it instead of 90 days, and §8 states the cost in terms. Four things still delete a story and all four are immediate: deleting the story, deleting the grid it belongs to, deleting your account, or withdrawing permission — which deletes every story on every grid at once. ⚠️ One of those was not actually true before this version, and is now. Deleting a grid was supposed to destroy its stories immediately; because a deleted grid is kept so it can be restored, nothing was removing them, and the 90-day sweep we have just retired was quietly doing that job. Deleting a grid now destroys its stories in the same operation. Nothing about what is sent, who receives it, or what we ask you before sending changed — the permission dialog is word for word the one you saw before, and it never mentioned a retention period.
3.0 2026-08-10 No text you can read on this page changed. What changed is what the document says about itself. Owner decision D7 records that no legal counsel will ever be engaged, so every internal note that said "counsel must settle this before publication" has been rewritten as an owner position, labelled not legal advice and not counsel-reviewed — the Art. 9(2) condition for server-stored grid content, the lawful basis for personal data about a third party the grid is about, the sign-in provider's role, and the transfer mechanism for every provider. None of them is now answered. Three conditions those notes carried are recorded as not met, rather than quietly dropped: the Art. 9 condition was to be settled before accounts shipped, the legitimate-interests assessment for third-party subjects was to exist before publishing shipped, and the per-provider transfer mechanism was to be stated before this policy published. All three shipped without them. The header no longer says the document is awaiting review; it says it was written by the owner and not reviewed by a lawyer. The DPIA §9 non-sign-off of the publish and story features stands — a decision not to seek review is not a review.
2.9 2026-08-10 A fourth sub-processor, and the first time we send something you wrote to another company. If you ask for a written life story, the labels you picked and your age in whole years at each one are sent to Anthropic, a language-model company in the United States. §6 gains a fourth row and the sentence "There are three" becomes "There are four". The safeguard column for that row is the weakest on the page and says so: we are on Anthropic's published terms, which carry the 2021 Standard Contractual Clauses and a no-training commitment, and we have no negotiated agreement and no term stopping them keeping what we send — we would rather write that than describe an assurance we do not hold. §3: three new rows — what is sent, the story itself, and the record of your permission — with the list of what is deliberately not sent (your birthdate, every date, your grid's name, the label naming its subject, your name, your email, every id). §5: the lawful basis is consent, and because those labels can carry health, faith, sex life or belief, explicit consent under Art. 9(2)(a) — a dialog before anything is sent, with everything on one screen, a recorded acceptance tied to the exact wording shown, and a withdrawal control that deletes the stories immediately rather than at expiry. §7: this is a new international transfer, relied on under those published Clauses, with no transfer assessment of our own — stated as the gap it is. §8: stories are kept 90 days, sooner on withdrawal, deletion of the grid, or deletion of the account. §12: a published grid never carries a story, there is no setting that would make it, and that is enforced in code rather than promised here. §13: life stories are no longer listed as a feature that does not exist. What did not change: signed out, nothing leaves your device — no part of this feature is reachable without an account, and nothing is sent without you accepting a dialog that names the recipient.
2.8 2026-08-09 Controller name changed to Offload Foundry. The controlling entity is unchanged — same company, same contact addresses, same processing; only the name it trades and is identified under has changed, from "Offload Solutions". §1 updated. Nothing about what we collect, who receives it, how long we keep it, or your rights changed in this revision.
2.7 2026-08-07 Two leftovers from 2.6 corrected, and one security claim made accurate. §3 and §10 still described a switch for turning on exact-date storage. There is no such switch — 2.6 removed it — so the consent-record row now describes the thing we genuinely do record consent for (publishing a grid), and the withdraw-consent right now names publishing rather than your birthdate. Nothing about what we hold changed; these two lines were describing a control that no longer exists, which is the kind of inaccuracy that reads as reassurance. §11's line about every read and write being authorised on the server against who owns it is confirmed as the operative description: the database-level policies that used to sit underneath that check were removed on 7 August 2026, and the check in our application code is now the only one — so the sentence is true, and it is now carrying more weight than it used to.
2.6 2026-08-04 We now store your dates exactly, and a published grid carries them. The service used to round every date it stored — your birthdate, and both ends of every chapter — to the year of life it fell in, with the exact day available only as an opt-in. That rounding is gone, and with it the opt-in: your exact date of birth and the exact date of every milestone and chapter are now stored on our servers whenever you are signed in. The reason is not commercial. The rounding silently destroyed the thing it was applied to — a chapter's length could not be edited, because every edit was quantised back to 1 January — and a minimisation control that corrupts a user's own content is not protecting them. §2, §3, §5, §9, §11 and §12 rewritten to say so plainly. §12 now states outright that publishing a grid publishes the dates in it, and that creating the link is how you agree to that; there is no setting that publishes the picture and withholds the dates. The lawful basis for these dates moves from consent (Art. 6(1)(a), opt-in) to contract (Art. 6(1)(b)) — they are the grid you asked us to save, and the service cannot hand back a grid it was not allowed to remember. What did not change: signed out, still nothing leaves your device, and that remains the default and the recommended way to use this. If you would rather we did not hold your exact birthdate, do not sign in.
2.5 2026-08-03 Technical context on usage events. Our own analytics now records, alongside each anonymous event, the technical details your browser announces to every website automatically: your browser's full identification string as sent, its family and major version, your operating system family, your device type, and your country. Nothing is read from your device and no new code runs in your browser — these are things the request already carried. §3: a new row. §4 rewritten: it lists each field, says why (browser-specific failures were previously undiagnosable), and states the refusals in the same breath — no IP address is stored at all, no page addresses, no referrers, and nothing that would let us recognise you on a later visit. §8: the retention asymmetry is recorded — the full identification string lives 90 days and is never carried into the 24-month counts, unlike the coarse fields. Struck from §4's "we don't collect" list: the claim that we keep no full browser identification string. We now do, and leaving that sentence in place would have been the most misleading thing on this page. What did not change: your birthdate still never leaves your device, no IP address is stored, the switch in Settings still turns all of it off, and there is still no cookie banner because we still store and read nothing on your device for analytics.
2.4 2026-07-30 The age restriction is gone. We no longer refuse accounts, publishing, or purchases to anyone on the basis of age, and no age check runs anywhere. §9 rewritten: it now says there is no minimum age, explains what protects a younger user instead (birth year rather than exact date, no advertising, no profiling, private by default, anonymous analytics), and gives parents and guardians a deletion route. §3: the row for the flag recording a blocked sign-up is removed, and so is the flag itself — the column was dropped from the database. §5: the lawful-basis row for the age check is removed with the processing it described. Nothing else about what we collect, who receives it, or how long we keep it changed.
2.3 2026-07-30 Usernames. Signed-in accounts now have a username you choose yourself, so the app can tell you which account your grid is saving to. §3: new row for the username, plus a short explanation of why it is a name you invent rather than one read from your Google profile — we deliberately did not ask Google for your name or profile picture, and no avatar image is fetched from anywhere. §4: the username is added to the list of things analytics never receives. §11: the breach paragraph now names it among what we hold. Nothing else about what we collect, who receives it, or how long we keep it changed; the sign-in scope Google sees is unchanged.
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@notify.offloadfoundry.com — a real address, read by a real person.