Draft: this document is not final; items marked “to be filled” will be completed before launch.

Privacy Policy (Draft)

Version 2026-10-24 · Draft, not yet finalised by counsel. Items marked "to be filled" will be completed by the operator before launch; items marked "unverified" mean the operator has not yet supplied the fact, which says neither "yes" nor "no".

1. Who We Are and How to Reach Us

• Operator (controller of personal data): to be filled
• Business address: to be filled
• Privacy contact email (with a named person responsible): to be filled
• When you make a data rights request, we reply within 30 days of receiving it (see section 6).

2. How to Read This Policy

• Two levels of recipients: we record third parties that receive data at two levels. The first is the direct recipient: the service or relay provider the request is actually sent to. The second is the actual model host: whoever really runs the model. A model's name does not prove who hosts it.
• Static defaults versus what is enabled: the routes in section 4 come from the static default configuration in the code. The admin console can change which routes are used; the routes actually enabled at launch are still unverified, and we will update this policy once they are verified.
• Some relay providers have no public terms, and data may be processed by their upstream providers.
• Retention: most categories have no single retention period. Below we state the actual rule for each one, and say so plainly where nothing is deleted automatically.
• Location: we do not promise that data is stored in only one country or region (see section 5).

3. The Data We Process

For each category: content, where it is stored, recipients (direct recipient → actual model host), identifiability, and retention and deletion. Sections 3.1–3.14 are the fourteen main data categories of the Service; sections 3.15–3.17 are additional categories.

3.1 Account data

• Content: email, username, user ID, VIP level and expiry, point balance.
• Stored in: the main database; your browser's local storage (user details held with the sign-in state); server logs may record the username.
• Recipients: the database and server hosts (see section 4.3). There is no evidence that the account record is sent whole to an AI model. The planned email service receives your email address for verification and password recovery; the planned payment processor receives the email and order identifiers needed for checkout.
• Identifiability: identifies you directly.
• Retention and deletion: kept while the account exists. There is currently no self-service way to delete or correct the account; ask manually as described in section 6.

3.2 Password and sign-in tokens

• Content: the password hash (the plain password is not stored), a token version number; access and refresh tokens in the browser.
• Stored in: the hash and token version in the main database; tokens in browser localStorage, with the access token also in a cookie.
• Recipients: passed only from the Service's frontend proxy to its backend; never sent to an AI model. Database backups contain the password hash.
• Identifiability: an authentication secret; a hash is not anonymous data.
• Retention and deletion: access tokens are valid for 12 hours, refresh tokens for 30 days. Signing out invalidates issued tokens and clears sign-in data on this device, but does not delete the account or the password hash.

3.3 Chat

• Content: messages you send, the idol's replies, drafts of messages that failed to send, and identifiers that prevent duplicate submission.
• Stored in: the main database; browser memory (chat history is not written to persistent browser storage).
• Recipients: the main LLM receives the current message, selected history, the idol's persona and relevant memories (static default direct recipient: DeepSeek; actual model host unverified). Memory extraction and the inner-life review process relevant excerpts again. The memory embedding service OpenRouter receives the query text used for retrieval, and OpenRouter chooses the downstream host dynamically.
• Identifiability: anything you type may include real identity, relationships, health or similar information.
• Retention and deletion: we keep your chat history, with no single retention period. Deleting an idol deletes that idol's chat records from the database; data already sent to third parties cannot be recalled through the Service.

3.4 Memories and profiles

• Content: memory atoms extracted from chats, scenario summaries, profiles of you and of the idol with their past versions, and the matching vectors.
• Stored in: the main database and vector tables.
• Recipients: the main LLM (memory extraction and profile generation); the OpenRouter embedding service receives the text of memories and scenarios, not only vectors. Our requests ask for zero data retention and deny data collection, but this does not fix the downstream host, country or region.
• Identifiability: derived data can still identify you; vectors are not anonymous data.
• Retention and deletion: memory decay is off by default, so memories are not deleted over time; profiles keep the latest 5 past versions by default. Deleting an idol deletes its memories, scenarios and profiles from the database, and the matching vectors are normally cleared with them; under some running conditions the vector cleanup is skipped, and we then cannot confirm those vectors were removed.

3.5 Inner state

• Content: the idol's mood value, experiences, worries and inner-review records. They are the state of a virtual character, but they arise from your interactions with it.
• Stored in: the main database.
• Recipients: summaries of mood and worries go into the chat prompt (main LLM); the full inner data is sent only to the inner-life LLM calls (by static default the same as the main LLM).
• Identifiability: may form inferences about you.
• Retention and deletion: a worry becoming "expired" or "resolved" is a change of state, not deletion; there is no single period. Deleted together with the idol.

3.6 Avatars, candidates and reference images

• Content: the idol's avatar, candidate images generated at creation, reference images you upload, temporary images made during processing, living-avatar videos.
• Stored in: the database holds file paths and generation records; files are written to the server's local storage first and then uploaded to object storage; your browser cache.
• Recipients: image generation routes receive the appearance description and the image data or a reachable address (static default first choice ephone; candidates include zz1cc, PoloAI and others); living-avatar videos go through the video route (static default CRUN); object storage receives the files.
• Identifiability: photos of real people identify them; idol images can also be linked to your account.
• Retention and deletion: no single period. Candidate generation records belong to your account, not to the idol, so deleting the idol does not delete them. Upload copies staged for a generation call are deleted when the call ends; if that fails, leftovers older than 24 hours are removed when the service starts.

3.7 Generated media works

• Content: images, videos, music, MVs and lyrics, with their prompts and parameters.
• Stored in: the database (work records, prompts, metadata, generation task records); files go to the server's local storage first and then to object storage; workstation drafts in the browser may contain lyrics.
• Recipients: LLMs such as the prompt optimiser, director and producer receive your descriptions; media generation routes receive prompts and reference images (images by static default ephone; video by static default CRUN; music by static default SunoAPI); lyric alignment also sends the task and track identifiers to SunoAPI.
• Identifiability: files, lyrics and prompts may contain names, likenesses, voices or identifiable scenes.
• Retention and deletion: no single period. Deleting an idol deletes its work records from the database, but not the files in object storage or on the server; generation task records are kept, no longer linked to the idol. Ask for manual file clean-up as described in section 6. Public addresses and caching of media files are covered in section 3.9.

3.8 Meetings

• Content: meeting inputs, the discussion between AI roles, plans and execution state.
• Stored in: the main database; run state in the browser.
• Recipients: the AI roles in the meeting (main LLM) receive the plan, character data and each other's discussion; during execution, image / video / music prompts go to the matching media generation routes.
• Identifiability: may contain your free text, works and information about people.
• Retention and deletion: no single period. Deleting an idol deletes its meeting records from the database, but not files in object storage or copies kept by processors.

3.9 Shared page and likes

• Content: the sharing switch and share-link token, work visibility settings, like records.
• What is public: once sharing is on, anyone with the link can see the idol's name, avatar, personality tags, bio, rating letter, like count and the works you made visible. The shared page does not show chats, worries, mood, affinity, level, experience, score details, free-text personality or profiles.
• Two kinds of address: the share token is the credential that opens the shared page's data; each work's image, video or music also has its own media file address.
• Turning off or resetting: afterwards the old token can no longer read the shared page's data, but media file addresses already handed out are not revoked, and addresses visitors already have keep working. Media files carry a cache setting of up to one year; after a file is deleted, copies in CDNs, browser caches, visitors' other devices and screenshots are outside our control.
• Recipients: anonymous visitors and their browser and network caches; the object storage and CDN provider.
• Identifiability: can be linked to a real or virtual identity; not showing the email does not make it anonymous.
• Retention and deletion: sharing settings and like records are deleted with the idol.

3.10 Payments and points

• Content: the point ledger, consumption orders and their processing records; order data at purchase, including billing country, tax-inclusive total, currency, product, the payment processor's customer / checkout / payment / event identifiers, refund and reconciliation records; the version, time and trusted IP of your acceptance of the Purchase Terms.
• Stored in: the main database. Full card numbers and security codes are collected only by the payment processor and never enter the Service's database.
• Recipients: the payment processor (Stripe planned; contracting entity unverified) receives payment details and the necessary email and order links. Tax is included in the listed price; we do not use the processor's automatic tax service.
• Identifiability: financial and transaction records can be linked to you.
• Retention and deletion: the point ledger is append-only and never rewritten; an account with financial records cannot be deleted directly. When we handle a request to delete an account, financial records are kept as accounting and legal duties require (retention period pending professional advice), and other content is handled as described in section 6.

3.11 Logs and operational records

• Content: request IDs, IP addresses, error stack traces, generation service call records (route, result, duration, cost), admin action audit, memory processing progress records.
• Stored in: server standard output and local log files; call records and audit tables in the main database.
• Recipients: the server and database hosts; the planned error monitoring service should receive only filtered errors, release versions and correlation IDs, never chat text; if a CDN proxy is enabled, the CDN provider processes network metadata.
• Identifiability: IPs, IDs and stack traces can be linked to you; parameters in SQL logs may contain chat text or email addresses. Truncating log fields and masking share tokens are not general anonymisation.
• Retention and deletion: generation service call records older than 30 days are cleared when the service starts, so they are kept longer while the service runs without a restart; the SQL log file has no built-in rotation; other logs have no single period.

3.12 Browser data and drafts

• Content: localStorage holds sign-in data, preferences and volume; sessionStorage holds workstation drafts, running task IDs, in-app messages and data handed between pages; chat history stays in memory only.
• Stored in: your browser.
• Recipients: none of it is uploaded automatically; it reaches the backend only when you submit.
• Identifiability: drafts may contain private text you have not sent.
• Retention and deletion: sessionStorage is normally cleared when the tab session ends; signing out clears several stores and caches on this device, but not copies in your other browsers, other devices or HTTP caches.

3.13 External publishing proof

• Content: the YouTube / TikTok / Instagram accounts and post links you register, publishing schedules, review jobs and verdicts.
• Stored in: the main database.
• Recipients: where the relevant credentials are enabled, we query public metadata from the YouTube Data API, TikTok oEmbed and Meta Instagram oEmbed; the review LLM receives the title, description, author and proof. The Service does not upload your content to these platforms.
• Identifiability: social account links can identify you directly.
• Retention and deletion: no single period; the related database records are deleted with the idol. Public content on the platforms is outside our control.

3.14 Backups

• Content: encrypted database backups (all tables, password hashes, provider configuration stored encrypted) and copies of media files.
• Stored in: planned daily encrypted database backups and media copies in separate private storage, with an off-site copy, rotated over 7 days plus 4 weeks; the database host also keeps a point-in-time recovery window.
• Recipients: the backup storage provider and authorised server administrators (entity and location to be filled); never sent to AI models.
• Identifiability: highly sensitive.
• Retention and deletion: data deleted from the main database disappears from backups only when those backups rotate out; deleting data from the main database does not immediately remove it from every backup.

3.15 Additional: consent records

• Content: the version and time of each legal document you accepted, the trusted IP, and a hash of the browser identifier (User-Agent).
• Stored in: the main database.
• Purpose: to show which version you accepted, for checking in a dispute.
• Retention and deletion: kept while the account record exists (the account record cannot currently be deleted directly; see section 6).

3.16 Additional: waitlist

• Content: the email you leave when registration is full.
• Stored in: the main database, with the email stored as ciphertext plus a lookup hash; the admin console shows only a mask.
• Recipients: the planned email service receives your email when an invitation is sent.
• Linking: if you later register, the waitlist record is linked to your account through the account ID. Data exports leave out the email ciphertext and hash, but that waitlist record can still be found and handled through your account.
• Retention and deletion: no single period; you can ask for deletion as described in section 6.

3.17 Additional: cultivation records

• Content: schedules and their review records, affinity, experience and level, rating snapshots.
• Stored in: the main database.
• Recipients: ratings and affinity are calculated inside the Service and not sent to AI models; schedules that need manual review are seen by administrators.
• Retention and deletion: no single period; deleted together with the idol.

4. Processor List

The tables follow the static default configuration; the routes actually enabled are set in the admin console and are still unverified. "No verifiable terms" means that when checked, no complete public terms and privacy notice from that processor could be found; it does not mean a breach has been shown.

4.1 AI models and generation routes

We cannot guarantee that every processor refrains from using the data it receives to improve or train models.

4.2 External publishing lookups (when enabled)

Google (YouTube Data API), TikTok (oEmbed), Meta (Instagram oEmbed): only metadata of the public accounts and posts you register is queried.

4.3 Infrastructure (planned; contracting entities and locations unverified)

5. International Transfers and Location

• We do not promise that data is stored in only one country or region.
• The main database's target region is Singapore and the server's target data centre is in Hong Kong; both are unverified.
• Your data is sent to the processors in section 4. According to their public notices, processing may take place in China, the US, the UK and elsewhere; for relay providers that publish no terms, the processing location is unknown.

6. Your Rights and Their Actual Scope

• Making a request: email the privacy contact (to be filled). We first verify your identity through your registered email address.
• Reply time: we reply within 30 days of receiving the request.
• Access and export: we manually export the database records linked to your account (machine-readable JSON) together with a list of where your media files are stored. The export leaves out password hashes, sign-in tokens, provider secrets, the waitlist email ciphertext and hash, and other users' personal data. It states what it covers and which categories it does not include.
• Correction: idol details can be edited in the app; other data such as the account email is corrected manually on request. After a change, old profile versions may still be kept under the rule in section 3.4.
• Deletion: handled manually. We work through your request item by item and tell you in our reply what was done and what could not be done. We delete the content in the database (idols, chats, memories, inner state, meetings, work records and so on) with the matching vectors (see section 3.4 for the limits of vector cleanup), and try to delete files in object storage and on the server from a list. The account record itself cannot currently be deleted directly: an account with financial records (the points granted at sign-up also create a ledger entry) has to keep its account record, and financial records are kept as in section 3.10. A process for removing identity data from the account (such as username and email) is not yet available; until it is, we can deactivate the account so it can no longer sign in or be used, but deactivation is not deletion and the username and email remain stored. Logs are kept under the rules in section 3.11, and backups disappear only when they rotate out.
• Copies held by processors: for processors that offer a deletion channel, we send a deletion request on your behalf and record the acknowledgement; for processors with no channel or no published terms, we tell you plainly that deletion "cannot be confirmed".
• Withdrawing sharing: you can turn the shared page off or reset it at any time; effects and limits are in section 3.9.
• Signing out: clears data on this device only; it does not delete data on our servers.
• The launch version has no self-service account deletion or export screen; all of the above go through the manual process.

7. How We Use Data

• To provide and run the Service: chat, generation, cultivation, sharing and billing.
• Security and abuse prevention: rate limits, content policy checks, takedowns and audit.
• Legal duties: financial bookkeeping, and responding to lawful regulatory or judicial requests.

8. Updates and Language

• When we update this policy we raise its version number; after a document required at registration is updated, you must accept the new version before starting new paid consumption.
• When we add or replace a processor or change where data is processed, we update this policy at the same time.
• This policy is available in Chinese, English and Malay. If the versions differ, the Chinese or English version prevails.