Staris Kids — Data Retention & Deletion Policy
Version: 1.0 · Effective date: 27 August 2026 · Controlling language: English. We also publish this document in Portuguese, Japanese, French, and Spanish; where the law of your place of residence entitles you to rely on the version in your own language, that version prevails for you to the extent of any inconsistency.
1. Purpose & scope
This policy explains how long Staris Kids keeps each category of information, how it is destroyed, and how you delete it — either individual items or your entire account. It is the published retention and destruction schedule expected of a service that processes facial images to make cartoon characters and of a children's service under the laws of our markets — the United States (COPPA, and Illinois' Biometric Information Privacy Act, which requires this schedule be publicly available), Australia (Privacy Act / APPs), Brazil (LGPD), Canada (PIPEDA / Québec Law 25), Japan (APPI), and our other markets — and it gives effect to Apple's in-app account-deletion requirement (App Review Guideline 5.1.1(v)) and Google Play's account-deletion policy.
Defined terms (You / Account Holder, Child, Uploaded Photo, Generated Content, Content, Biometric Data, Service, Subprocessor) carry the same meaning as in the Terms of Use and Privacy Policy. Deletion is always initiated and controlled by the adult Account Holder; we provide no Child account. We keep information only as long as we need it, and no longer, except where the law requires a limited record. We do not retain personal information indefinitely.
2. Retention & destruction schedule
Two structural facts control everything else:
- The App uses photographs in two different ways. A Character Photo (a photo turned into a cartoon character) is never written to storage at all. Memory Story photos (photos added to a Memory story so it can be written about a real event) are written to storage, then deleted automatically once read — they must be uploaded because our AI provider reads them from a link. Neither is retained.
- Raw Character Photos are never stored — held only in memory, sent to OpenAI in a single generation flow to produce a cartoon, then discarded (see §3).
- The photo is never stored; a written description derived from it is kept (see §4). The facial-characteristic analysis produces a short set of words describing appearance, which is retained for as long as it is needed to keep your character looking like itself and visually consistent across stories — in two separate contexts, each with its own destruction trigger. We treat it as biometric information wherever applicable law requires us to do so. It arises only from a Character Photo; Memory Story photos are not subject to facial recognition or biometric identification, and no facial geometry or biometric template is derived from them (see §3b).
| Data category | Store | Retention period | Destruction method |
|---|---|---|---|
| Raw Character Photo | Not stored — in-memory only, in-flight to OpenAI | Not retained — one vision + one image call, then discarded; EXIF/geolocation stripped first | Released from memory immediately; never written to disk, DB, or backup |
| Memory Story photos (up to 8 per Memory story) | Written to a private, non-public area of our storage scoped to your account, in Australia (Sydney ap-southeast-2); no public URL, reachable only by signed expiring link |
The duration of one request — seconds. Deleted as soon as the single vision pass returns, on the success path and the failure path alike. Drafts hold no photographs. EXIF/geolocation removed on-device before upload (resize + re-encode) | Automatic, in the story-drafting step immediately after the analysis. Backstops: a stale-orphan sweep (>1 h) for interrupted uploads, and account deletion, which sweeps the whole photo area scoped to your account |
| Biometric Data (facial-characteristic analysis, kept as a written appearance description — never the photo) | Supabase (Australia) — with the character, and inside stories already generated | Two contexts: with the character, the life of the character; inside a generated story, the life of that story. Both subject to the outer bound above | Character copy deleted on character deletion, withdrawal of photo consent, or account deletion; story copy deleted when that story or the account is deleted |
| Derived cartoon portrait | Our private image storage, linked to the character record | Life of the character/account, or until you delete it or withdraw consent. Outer bound: destroyed once its purpose is satisfied or within 3 years of your last account interaction, whichever is first | Deleted from storage + DB on item deletion, account deletion, or consent withdrawal |
| Character identity metadata (appearance summary, identity details, traits, outfit) | Our database, with the character record and its links to stories | Life of the account, or until you delete the character | Record deletion on item/account deletion |
| Identity: email + password | Supabase — sign-in credentials + account profile | Life of the account | Record deletion on account deletion; the server-side purge cascades from the account record |
| Child profile (nickname, age range, interests, language, extra-gentle, transitions) | Supabase — account profile | Life of the account | Record deletion on account deletion |
| Generated Content (stories, pages, covers, memory, Quick Learns) | Supabase + image storage | Life of the account. Remains readable after a subscription lapses — deleted only on item/account deletion | Record + asset deletion on item/account deletion |
| Photo-consent record (account ID, policy version, time granted, IP address, browser/device user-agent) | Supabase | Kept as consent proof for the life of the account (plus a short limitation-period tail where the law requires evidence of lawful processing) | Deleted / de-identified when the basis ends; withdrawal logged (see §5, §10) |
| Subscription & billing records (billing events, plan and add-on credit balances, the usage ledger and plan counters) | Supabase; Apple, RevenueCat | ~7 years, or as long as tax, accounting, and consumer law require, even after account deletion | Purged when the legal retention period ends (see §6) |
| Server telemetry (AI-usage events, generation runs, story-engagement and story-quality records, guide feedback, world-usage events, engagement summaries) | Supabase | ~12 months, then deleted or aggregated/de-identified | Record deletion or irreversible aggregation; tied to account deletion where still identifiable |
| Product/user content & state (custom worlds, favorites, your living worlds, your story series and episode unlocks, character world states) | Supabase | Life of the account, or until you delete the item | Record + asset deletion on item/account deletion |
| Background processing jobs (story-memory extraction) | Supabase | Transient; then ~12 months as operational telemetry or sooner | Record deletion at end of window; purged on account deletion while identifiable |
| Crash diagnostics | Firebase Crashlytics (Google) — crash reports only; no analytics SDK ships in the App | Per Google's controls; no advertising identifier, no cross-app tracking | Deleted on Google's schedule (see the Privacy Policy §6) |
| Purchase attribution | RevenueCat | Per RevenueCat's controls | RevenueCat instructed to delete on account deletion (§9) |
| Auth tokens | Device secure storage (iOS Keychain / Android Keystore-encrypted storage) + local settings store (on-device) | Session lifetime / rotation | Cleared on sign-out and account deletion (local device only) |
| Story share links (the link's identifier, which story it points to, the optional note, expiry, and a plain count of web opens) | Supabase, Australia (Sydney ap-southeast-2) |
10 days from creation, or until you remove the link — whichever is first. Removed automatically when the story or the account is deleted | Record deletion; a link stops working immediately on expiry, removal, or deletion of the story or account |
| Web request records for shared-link pages | Our hosting provider's standard server logs | A short operational period set by our hosting provider's standard log settings — these records are not kept by us beyond that, and are used only to keep the service running and secure | Overwritten automatically on the provider's normal cycle |
| Content reports (who reported — where known — which content, the reason chosen, any note added, and how it was resolved) | Supabase, Australia (Sydney ap-southeast-2) |
Life of the account, plus a short tail where a report is evidence of a safety matter we are required to keep. A report made from a shared web page carries no reporter identity | Record deletion on account deletion, except where the law requires the limited record in §6 |
Dormant accounts. If an account shows no activity of any kind for ~24 months — not merely no sign-in, but no use of the Service at all — we treat it as dormant and delete or de-identify it and its personal data on the same basis as an account deletion (§8–§9), keeping only the limited legal records in §6. Where feasible we notify the account email first.
3. Character Photos are never stored
When you add a Character Photo — a photograph of a real person that you turn into a cartoon character — it is processed only in memory. Identifying metadata (such as EXIF geolocation) is stripped first. The photo is transmitted to OpenAI in a single generation flow to (a) analyze facial characteristics and (b) render a cartoon, then discarded. The original photo is never written to our storage, databases, logs, or backups — because it is never written anywhere, there is nothing for a backup or log to contain. We have verified this in code and by live test. What we retain is the derived generated cartoon portrait and the written appearance description described in §4 — the portrait is a stylized drawing rather than a photograph, but it is drawn to resemble the person, so we do not claim it cannot be recognised as them. We have turned off data logging on our OpenAI account, and OpenAI does not train on the image. We do not hold a Zero Data Retention arrangement with OpenAI, and we do not claim one. Under OpenAI's API terms the transmitted image may be retained for up to 30 days for service operation and abuse monitoring and is then deleted; it may be kept longer only where the law requires it, or where OpenAI's automated safety checks flag content for review. (For other deleted data — not photos — residual copies in encrypted operational backups are purged within our provider's backup-retention window; see §10.)
3b. Memory Story photos — written, read once, then deleted
A Memory story is written about something that really happened, so you may attach up to eight photographs of the event. This is a different feature from creating a character, and it works differently: a Character Photo never touches our storage, whereas a Memory Story photo must be written there because OpenAI reads it from a link rather than from the message we send. Because §3 makes an absolute promise about Character Photos, this section states the Memory Story position without hedging:
| Question | Answer |
|---|---|
| Are they sent to OpenAI? | Yes. OpenAI (GPT-4o mini vision) is given a time-limited private link and reads each photo once, in a single analysis pass, to produce a short written description of the memory. OpenAI does not train on it; any abuse-monitoring copy is retained for up to 30 days and then deleted — longer only where the law requires it, or where automated safety checks flag content for review. |
| Are they stored at all? | Briefly, yes. They are written to a private, non-public bucket in Australia (Sydney ap-southeast-2), under a path scoped to your account. There is no public address; access is by signed, expiring link only. |
| Are they held only temporarily? | Yes — the duration of a single request, normally seconds. They are deleted the moment the vision pass returns. They are not kept for the life of the draft: a draft is rebuilt from the written description, never from the pictures. |
| Is identifying metadata removed? | Yes. Before the photo leaves your device it is resized and re-encoded into a new image file, which does not carry the original EXIF — including GPS coordinates, capture time and device identifiers. Only the re-encoded image reaches us. |
| What is generated from them? | Story text only. The analysis yields a written description of the occasion, the people present, the apparent kind of place, and the objects and details, and that description shapes the drafted story. Illustrations are not drawn from them — illustrations come from the story text and from your characters' existing cartoon portraits. The photo itself is never displayed in the App and never printed into a story page. |
| Are they deleted after generation? | Yes, automatically — and sooner than "after generation". Deletion runs as soon as the analysis returns, before the story text is drafted, and it runs on the failure path too (a retry re-uploads from the device). Because a saved draft holds no photographs, finishing a story, discarding a draft and cancelling part-way all leave nothing behind. |
No facial recognition or biometric identification. Understanding a photograph necessarily involves the AI system processing the people visible in it, but Memory Story photos are not used to derive facial geometry, to create a biometric identifier or template, to build a likeness of anyone, or to recognise or match a person. They therefore do not create the Biometric Data described in §4, and the biometric consent in the Consent & Eligibility Policy does not extend to them. We also instruct the model not to attempt precise geolocation.
What happens if something goes wrong. Two failure paths are covered explicitly. (a) If the analysis itself fails, the photographs are deleted anyway — deletion is not conditional on success. (b) If the upload is interrupted before the request is issued (you cancel mid-upload, the app closes, the network drops), the app removes what already landed, and a stale-orphan sweep clears anything older than one hour that is still present. Deleting your account purges the whole area regardless.
Backups. Because these photos are briefly written to storage, a residual copy may exist in an encrypted operational backup taken during that short window, and is purged within our provider's backup-retention window (§10) — unlike Character Photos, for which there is nothing to purge.
4. Biometric Data — what is derived, what is kept, and for how long
Making a cartoon involves analyzing facial characteristics in the Character Photo — Biometric Data used only to create and maintain a cartoon likeness, never to identify, verify, or match a person, and never to build an identity database. We perform no face matching, and do not sell, lease, trade, or profit from Biometric Data.
The raw Character Photo is never stored. It is held only in memory, sent to our AI provider in a single generation flow, and discarded immediately — never written to disk, database, or backup (§3).
A written description derived from it is kept. The analysis produces a short set of words describing that person's appearance. It is not the photograph, and it is retained for one reason: a character drawn today must still look like itself in a story generated a year from now. It is kept in two separate contexts, each with its own destruction trigger:
| Context | Kept for | Destroyed when |
|---|---|---|
| With the character — the active description used to draw that character again | The life of the character | You delete the character · you withdraw photo consent · you delete your account · or the §2 outer bound is reached, whichever comes first |
| Inside a story already generated — the description frozen into the pages of that story when its illustrations were made | The life of that story | You delete that story, or you delete your account |
Why withdrawal does not reach the second copy. Withdrawing consent stops all further analysis and deletes the active description together with the cartoon portrait and the character. The description already frozen into stories you have generated stays with those stories, so the illustrations you already have remain coherent. It cannot be used to create a new character, seed a new story, restore a deleted character, or for any other purpose, and it is never used to identify anyone. To remove it, delete those stories individually or delete your account.
Published destruction commitment: the raw Character Photo is destroyed immediately upon completion of cartoon generation — within minutes, and in no case beyond 24 hours. The derived description and the generated cartoon portrait are destroyed on the triggers in the table above, and in every case no later than the §2 outer bound.
5. Photo-consent records
We keep a record that consent was obtained (account ID, policy version, timestamp, IP address, browser/device user-agent) as proof of lawful processing, separate from the Character Photo (which is never stored), for the life of the account plus a short limitation-period tail where the law requires evidence of lawful processing (see §6).
This record is append-only, and withdrawal is logged rather than erased. Withdrawing photo consent does not delete the record that consent was once given — it adds a withdrawal entry that supersedes it, with its own timestamp. That is what allows us to evidence both the consent and its withdrawal, which is the whole purpose of keeping the record. Deleting your account removes the record along with the rest of your data, except where the law requires us to retain proof of lawful processing (§6).
6. Billing, tax & legal records
Subscription, purchase, and transaction records are retained for ~7 years, or as long as tax, accounting, consumer-protection, and audit law require, even after you delete your account — the financial record is kept de-identified (the account identifier on the billing records is erased on deletion). Apple and RevenueCat also keep their own transaction records. We also keep minimal security/abuse records and the minimal consent-proof record where the law requires. These are limited, access-controlled, and used for no other purpose.
7. Telemetry & analytics windows
- Server telemetry — ~12 months, then deleted or irreversibly aggregated/de-identified; purged on account deletion while still linked to an account.
- Crash diagnostics (Firebase Crashlytics) are the only third-party telemetry in the App — Firebase Analytics is not included, so there is no advertising identifier and no ad-conversion API. Retention runs on Google's controls. Product-usage measurement is first-party only and stays in our own Australian database (rows above). See the Privacy Policy §6.
8. Your right to delete
You can delete your information at any time, directly in the App:
- Individual items — delete a character directly from your character library (removes its record, identity metadata, and derived portrait; there is no separate raw photo to erase because none is stored) or a story from your stories list (removes the story, pages, cover, generated assets, and memory). Deleting a character does not delete stories already made with it — those keep the illustrations they were generated with; delete them individually or delete the account. Favorites can be removed by un-favoriting. For item types without an in-app delete control yet (for example, a custom story world), delete the account or ask us and we will remove it (§11).
- Your entire account — from Settings → Delete Account. The flow confirms your intent and re-authenticates you, so deletion is deliberate. Deletion is permanent and irreversible — deactivation/sign-out is not a substitute and is insufficient under Apple 5.1.1(v). It is implemented: the in-app flow runs a server-side purge that permanently erases your data on our systems.
- Withdraw photo/biometric consent deletes the derived portrait and the character associated with that consent and stops further processing.
Deleting is different from cancelling a subscription: cancelling stops billing (via Apple or Google Play) but keeps your account and Content; Content you already created or unlocked stays readable after a subscription lapses — it is removed only when you delete the item or the account.
9. What the backend purge covers
When you delete your account, we purge your personal data, including: identity (your sign-in credentials and account profile); child profile; characters + derived cartoon portraits, and the links between characters and stories; Generated Content (stories, pages, covers, story memory and Quick Learns, together with their images); any Memory Story photos an interrupted upload left behind (the whole private photo area scoped to your account — see §3b); worlds & library state (custom worlds, favorites, your living worlds, your story series and episode unlocks, character world states); identifiable telemetry (world-usage events, story-engagement summaries and background story-memory extraction jobs; the AI-usage, generation-run and story-quality records, which do not cascade automatically, are hard-deleted); and on-device data (secure-storage tokens + local settings cleared). We also instruct Subprocessors to delete their copies — RevenueCat (subscriber-delete API), OpenAI (retains no stored dataset of your photos/prompts; any abuse-monitoring copy expires within 30 days, longer only where the law requires it or where automated safety checks flag content for review; none used for training) — while Apple and Google keep their own transaction records under their own terms, and Firebase Crashlytics crash diagnostics (device-level signals not tied to your account identity) age out on Google's retention schedule. Raw Character Photos are not part of the purge because they were never stored (§3). The appearance descriptions derived from them ARE purged — both the copy held with each character and the copy frozen inside your stories go with the characters and stories themselves (§4). Memory Story photos are normally already gone — deleted seconds after upload (§3b) — so the purge exists to catch anything an interrupted upload left behind. The only exceptions retained are the limited legal records in §6.
10. Timeframe
In-app account deletion runs the server-side purge immediately on confirmation; we complete any remaining backend purge and Subprocessor deletion instructions within ~30 days, except the §6 legal records. Some Subprocessor and backup systems take a short additional period to overwrite residual copies on their normal cycles.
11. Requests you cannot complete in-app
If you cannot complete a deletion in the App, or want us to erase a specific item, email support@cleverlabs.com.au; we verify through the Account Holder before acting. Residents of our markets — including the United States, Australia, Brazil, Canada including Québec, and Japan — also have the statutory access, correction, and deletion rights described in the Privacy Policy.
12. Changes
We may update this policy; we will change the version and effective date above and give notice of material changes. Questions: support@cleverlabs.com.au.