Privacy Policy
What data we collect, why, and the rights you have over it.
Data controller
The data controller is to be confirmed once the operating entity is registered. The Contact page reaches an operations mailbox where this deployment configures outgoing mail, and says after you submit whether your message left the server; where it does not, it names the address to write to instead, or admits that none is published. A postal address and a named controller are still required before launch.
Data we collect
Account data (name, email, password hash), the images you upload, the assets you generate, billing data handled by the payment provider, usage data, device and log data, support messages, and the consent records linked to real-person uploads.
Purposes and legal bases
Data is processed to run generations, keep your Library, secure accounts, bill usage, provide support, and meet legal obligations.
The mapping of each purpose to its legal basis (contract, consent, legitimate interest, legal obligation) will be finalised during legal review.
Real-person uploads
Uploading a real person requires confirming you have the rights and their consent. That confirmation is recorded as a consent record. People depicted without consent can request removal without an account.
Providers and subprocessors
Third-party providers process data on our behalf. Images you upload, including photographs of real people, are sent to Google for generation; billing data is processed by Stripe. Storage and sign-in run on our own infrastructure. The full list, with the purpose and the categories of data for each provider, is published on the Subprocessors page.
International transfers
Google and Stripe are established providers that may process data outside your region. The applicable transfer mechanism for each of them is not yet documented; the Subprocessors page states this openly and must be completed before launch. Do not read the absence of a documented mechanism as an absence of transfer.
Retention
Your creations are private by default. Removing an asset from your Library moves it to Trash, where it stays for 30 days: you can restore it, or delete it for good straight away from the Trash itself. Whichever comes first — your own permanent deletion or the 30 days running out — the stored file is erased from our object storage and the identifying fields of its record are emptied. One case is postponed rather than done at once: while a generation you started is still reading that asset, an immediate deletion is declined and you are asked to try again once it finishes, so that a generation you paid for cannot be left without a result; the automatic pass retries on its own.
What survives that erasure is a stripped record. Everything that described the image is gone: name, stored file, checksum, original file name, format, size, dimensions, tags, style, tone and the rights and consent confirmations you made when you uploaded it. What is deliberately kept is accounting and filing metadata: the record identifier, the account it belongs to, whether it was an upload or a generated result, the credits it cost and the link to the credit transaction that paid for it, the folder it was filed in and the projects or collections it was added to, and the dates it was created, last changed, moved to Trash and erased. The database refuses to drop the row itself, because upload and generation records point at it. Two consequences, so that the residue is not read as smaller than it is: the record stays attached to your account, and it stays attached to containers you named yourself, even though the erased asset is no longer shown or counted anywhere in the product.
An image you uploaded is described twice, so it is stripped twice. Besides the Library record, the upload ticket that carried your file in is emptied in the same operation: the checksum, the original file name, the format, the size, the dimensions, the storage locations and the two request fingerprints derived from them are removed there as well. What that ticket keeps is the identifier of the ticket itself, the two idempotency keys your client generated for it — random values that say nothing about the image — the state of the reservation, the link back to the stripped record, and the dates of the ticket: when it was opened, when it expired, when its temporary copy was deleted and when it last changed. They are kept for one reason: a retried upload must be recognised as the same upload instead of reserving, storing and charging a second time.
One residue this does not yet reach, named here rather than left to be discovered: for an image the service generated rather than one you uploaded, the generation record that produced it keeps its own copy of the storage location, the checksum, the format, the size and the dimensions. Erasing the asset empties the Library record and destroys the stored file, but leaves that copy standing. It is a known gap, not a design — the same stripping is owed there and has not been built yet.
A second residue, narrower, and closable only by hand. An upload is carried in through a temporary copy that is deleted once the image is filed. Before this version, when that clean-up failed the failure was recorded and the upload went through anyway, and erasing the asset never came back to it. For those older uploads only, the erasure still empties everything that describes the image, but keeps one field: the location of that temporary copy. That location is a random value nothing can recompute, so dropping it would leave the file sitting in storage with nothing left pointing at it — worse than keeping the pointer. So for those uploads the temporary copy may still be stored, and its recorded location still gives away the file format through its extension. Nothing in the running service closes this: an operator has to delete each remaining copy and clear its location, following a documented procedure. It cannot happen to an upload made from this version on — every erasure now destroys both copies in the same operation.
Two limits, stated plainly. Deleting an asset does not reach the images generated from it: those results are separate assets and stay in your Library until you remove them too. And the 30 days cover the Library Trash only — a generated result you keep carries no expiry date. Retention periods for every other category of data are to be defined after legal and operational review. Until then, assume that data sent to the service is kept.
Security
The intended security practices are described in the Security overview. They are production requirements and must be verified before launch.
Your rights
Depending on your jurisdiction you may have rights of access, correction, deletion, objection, restriction and portability. The Contact and Content removal forms are the route for such a request: they send it to an operations mailbox where this deployment configures outgoing mail, and say after you submit whether it actually left the server. Exercising a right still requires a person to act on it: the Privacy centre simulates export and account deletion without performing either, and no response time is promised, because none could be honoured.
A published contact address and a working request procedure are required before launch. Until they exist, the only avenue that does not depend on us is a complaint to your supervisory authority, which you may lodge at any time.
Two controls do take effect on their own. “Cookie settings” in the footer records your choice in your own browser and can be changed or withdrawn at any time. And from your Library Trash you can delete an asset for good: the stored file is really erased, without anyone acting on a request. One temporary exception applies to that second control: while a generation you started is still reading the asset, the deletion is declined and you are asked to try again once it finishes. It covers the asset you uploaded, not the images generated from it, it leaves the stripped record described in the Retention section, and it is not account deletion — the Privacy centre screen offering that one is a preview and deletes nothing.
The content removal and appeal routes send your request to a person; they never remove or reinstate anything automatically.
Automated processing
Image generation involves automated processing of the images you upload. No decision producing legal effects is made solely by automated means.
Minors
The service is not directed at minors. Age thresholds and verification measures will be confirmed during legal review.
Updates to this policy
Material changes will be announced in the product before taking effect.