Privacy policy

Private Edition · Version 1.1 · 29 August 2026

This policy explains what Private Edition does with your information. It is written against what the software actually does. Where the software does not yet do something you might expect, this policy says so instead of promising it.

1. What we collect

Your photographs and videos

The core of the product is your own photographs. When you import or capture a photo or a video, the file is stored so we can work on it. We also store the working copies the editor makes, the previews it shows you, the finished files you unlock, and any archives you export.

For each file we record technical facts about it: its type, size, dimensions, duration, a checksum, and probed details such as frame rate and colour space.

Your face

Your photographs contain your face, so we process facial likeness. Two features work on it directly:

• Retouching. The editor detects faces and skin in the image in order to work on them. This happens on our servers while the render runs.
• Identity profiles. If you create one, you take several guided captures from different angles. Those photographs are uploaded and stored the same way as any other photograph you import into a project, and are deleted with it. The profile record itself holds a display name, the list of traits you want preserved, and a link to the consent you gave.

We do not compute or store a face template, a face embedding, or any other mathematical representation of your face that could be used to recognise you elsewhere. There is no face-recognition system in this product and no face database to search.

Read this before you decide to make one. In this release the guided captures are not used by the AI photoshoot. They are stored, and they are yours to delete, but nothing attaches them to a generation: no photograph of you is sent to the image model, and a generated shoot is not conditioned on your appearance — it is built from the collection and controls you chose. Section 4 sets out the entire content of a generation request. Sending a reference photograph is what would make a generated shoot resemble you closely; if we enable it, this policy will be re-versioned and fresh consent recorded before a photograph of your face leaves our servers.

The traits you can ask to have preserved are things like exact facial geometry, skin tone, skin texture, tattoos and marks, facial hair, and body proportions. Those are protections, not measurements: they are instructions the generation pipeline is required to respect, and they are attached to every AI shoot request whether or not you have a profile.

Location inside photographs

Camera files often carry a GPS fix. The app never asks for your location and holds no location permission, but a photograph you import can carry one inside it, so here is exactly what happens to it.

• Your original is stored exactly as you gave it to us, byte for byte, including any GPS coordinates, camera tags and the time of capture. Nothing is re-encoded and nothing is stripped. We do not read that metadata into our database and we do not use it for anything.
• Every rendered copy carries no metadata at all. A protected preview, a clean final and any working copy are re-encoded from the pixels by the render pipeline, and that re-encode drops every tag, the GPS ones included. Our test suite checks that a rendered derivative comes out with no EXIF, IPTC or XMP payload.
• A copy of your data that you export contains your originals as stored, so it can contain that GPS fix. It is your file and your archive, delivered only to you over a short-lived link bound to your account.
• Nothing carrying a photograph is sent to any other company. Section 4 lists the entire content of the one request that leaves our servers, and it has no image in it.

An earlier version of this policy said that copies made for the cloud and files placed in an export were re-encoded through an allowlist of camera tags, so coordinates were removed by default. That described a module we wrote and never connected to the upload path. It was not true of the stored original or of the export archive, and it is corrected above rather than left as a control you could rely on. Because the stored original can hold a coordinate, we declare precise location as data this app collects on the app stores, even though no feature reads it.

Account and sign-in

An account record holds an internal id, its status, whether it is still a guest account, your email address if we have one, an age band, your language, and dates. Sign-in works through Apple, Google or an emailed code; we store which provider you used and the identifier that provider uses for you. Sessions are stored as a hash of the session token, never the token.

Devices

For each device signed in we store its platform, app version, a name, when it was last seen, and the result of a device-integrity check. If you turn on notifications we store a hash of the push token, not the token itself.

Your consents

Each consent you give or withdraw is stored as its own dated record with the version of the policy it was given against. Media processing, identity profiles and analytics are separate records — agreeing to one is not agreeing to another. The most recent record wins, so you can change your mind, and change it back.

What you make

Projects, edit histories, presets, and — for the AI shoot — the concept category, the controls you set, the recipe, the parts you locked and the random seed used. These are kept so a result can be reproduced and revised.

Safety decisions

Requests and outputs are screened against a content policy. We store the decision, the policy codes behind it, and any appeal.

Billing

Subscriptions and credit packs are sold by the Apple App Store and Google Play. We store the store name, the store's transaction identifier, the product, the amount and currency the store reported, the state of the purchase, and a hash of the receipt.

We never see your card. Payment details are handled entirely by Apple or Google and are never sent to us.

Support

If you contact support we store the conversation. If you attach a screenshot it is stored like any other media file — encrypted, in the same object store — because a screenshot of this app usually contains your photographs.

Records of privileged access

Every privileged action writes an audit record: who did it, what they did, what they did it to, when, and the reason code they gave. These records store a hash of the before and after state rather than a copy of it, so the audit trail can prove that something changed without becoming a second copy of your private data.

2. Where it is stored, and how it is encrypted

Files go to an object store: either a directory on our server or a cloud bucket, depending on how the service is deployed.

Before anything is written, it is encrypted. Every file gets its own randomly generated 256-bit key. That key encrypts the file with AES-256-GCM, and is itself wrapped by a master key that lives in the deployment's secret store. Both layers are bound to the file's own storage path, so encrypted bytes cannot be moved from one file to another, and a single altered byte causes the read to fail rather than to produce garbage.

Two refusals are built in, so this cannot quietly stop being true:

• A production process will not start without a real master key. It cannot fall back to the development key.
• A production process will not start with encryption turned off while files are stored on a plain directory.

When a cloud bucket is used, the bucket's own server-side encryption is enabled as well, and files are labelled as opaque data so that a misconfigured server cannot serve them as images.

What this protects against, plainly: anyone who obtains the stored bytes without the master key — a mis-scoped bucket, a stolen disk, a backup copy, the storage provider itself. What it does not protect against: our own running service, which necessarily holds the master key while it is serving your requests. No storage encryption anywhere protects against that, and we would rather say so than let the word "encrypted" do work it cannot do.

The database that holds the records described in section 1 — account, projects, consents, purchases, audit — is protected by the encryption our database host provides. The application does not add a second layer of its own to those rows.

3. Who can look at your photographs

You

Your app never receives a storage path. It receives a signed link, valid for five minutes, tied to one file and to your account, and issued only after two independent checks pass: that the file is yours, is not deleted and has not expired; and, for a clean unwatermarked master, that a recorded unlock exists for it. Protected previews are watermarked with a preview identifier and a partially masked account id, so a leaked preview can be traced.

Our staff

This is the part most privacy policies leave vague, so here is exactly how it works.

Staff accounts have roles. No role carries standing permission to open user media. Opening a user's media requires a just-in-time elevation: a separate grant that

• requires a reason code from a fixed list — support ticket, abuse investigation, billing dispute, legal request, incident response, safety appeal, account administration;
• requires free text saying which ticket, case or incident this is;
• expires. The default window is 15 minutes and the maximum is 60. Expiry is checked at the moment of use, so a forgotten grant closes itself;
• can be revoked before it expires.

Every grant, every use of a grant, and every attempt made without one is written to the audit trail with the reason code attached. "Who opened this user's media, when, and why" is a question the system can answer after the fact. Staff spend almost all of their time with no ability to open your media at all.

The administration console is served only to network locations on a configured allowlist, and it loads no code from anywhere but our own service.

4. What is sent to AI providers, and when

Most of what this app does never leaves our servers.

• Photo retouching — including all face and skin work — runs on our own servers. Your photograph is not sent to any AI company for this.
• Video runs on our own servers.
• Content safety screening runs on our own servers.

The AI photoshoot is the one feature that can call an outside image model. Two conditions must both be true before that can happen: the deployment must hold that provider's API key, and an administrator must have added a routing entry selecting it. Without both, the request is served by our own local generator, and there is no configuration in which an outside provider is used by accident.

When such a call is made, this is its entire content:

• the prompt text, assembled from the shoot collection you picked and the controls you set;
• the constraints that forbid impersonation and forbid altering skin tone, facial geometry and body proportions;
• the aspect ratio, a random seed, and the output image format.

It carries no account identifier, no email address, no device identifier and no name.

It also carries no photograph. The provider adapters are built to send one reference image, and today the app passes them an empty reference list at every call site, so no image of you is sent. The consequence is worth stating in the same breath, because it is a limitation and not only a privacy property: a generated frame is not conditioned on your identity profile and is not a picture of you. It is built from the collection, the controls and the constraints listed above. If reference conditioning is switched on — which is what would make a generated shoot resemble you closely — a photograph of your face will be sent to that provider on each generation. That is a material change, and this policy will be updated and re-versioned before it is enabled.

Generated images that come back are screened before you see them, watermarked, and stored the same way as everything else.

5. Other companies your information reaches

This is the named sub-processor list that earlier versions of this policy promised at launch. Three companies are engaged: Stability AI generates AI photoshoot frames from the text described in section 4; Resend delivers sign-in code emails; Railway hosts the service and stores its encrypted files and database. Each is bound by its own terms to process this data only to provide that service to us, and not for its own purposes. Stability AI is the only AI company in this list, it is used only for the AI photoshoot, and — as section 4 sets out in full — what reaches it is text, never your photograph. Photo retouching, video and safety screening never reach any of the three except as encrypted storage at Railway. If we engage another sub-processor, or if what one of them receives changes, this list and this policy are re-versioned first.

We do not sell your information. We do not share it for advertising. There is no advertising in this product.

6. Analytics

The app records your analytics choice as a dated consent, and you can change it at any time in Settings and privacy.

At present there is no product-analytics pipeline in this service. There is no analytics event store and no analytics vendor. The consent control exists and your answer is recorded, and it is the control that would govern analytics if any are added. Turning analytics off does not limit any feature.

If analytics are added, the rule the code already enforces elsewhere applies: no raw media, no prompts, no protected traits and no precise location may enter a general analytics system.

7. How long we keep things

A sweep runs on a schedule, deletes the stored bytes of anything whose expiry date has passed, and then marks the record deleted. Every clock in the table above is set when the file is written, so nothing depends on someone remembering to set one later. On cloud storage a bucket lifecycle rule on the same classes is a second, independent backstop.

Two honest qualifications. The sweep runs inside our background worker process, so a deployment that does not run that process — which is not how this service is deployed — would enforce the expiry dates only as a refusal to open the file, not as a deletion. And a sweep that runs every few minutes means "24 hours" is a deadline rather than a stopwatch: a working file is gone within the interval after its day is up, not on the second.

8. Deleting your account

You can delete your account from Settings and privacy in the app. You confirm who you are, you are shown the list of what will be removed, and then:

• every signed-in session is revoked immediately, on every device;
• the account is marked for deletion and a receipt is created listing each category and its state;
• the scheduled job deletes the stored bytes of every file you own, and marks your media, identity profiles and projects deleted;
• your email address is removed from the account record and the account is marked deleted.

The receipt is honest about what is not instant. Encrypted backups are listed as held, with the 35-day schedule stated, rather than reported as already gone. Billing records and the audit trail are retained separately from your media, as the law requires, and are never used to bring your account back.

Two categories on that receipt describe systems that do not exist yet. "Copies held by AI providers on our behalf" is listed because no AI provider currently holds any copy of your media — see section 4 — and the category is there so it is covered if that changes. "Analytics records tied to your account" is listed for the same reason: there is no analytics store today, as section 6 explains. Both are marked complete because there is nothing in them, not because a purge ran.

Deleting your account does not cancel your subscription. Subscriptions are billed by the app store and only the app store can cancel them. The app says so at the moment you delete, and section 5 of the terms says so too.

9. Getting a copy of your data

In Settings and privacy, "Build a copy of my data" produces a downloadable archive. It contains your account record, sign-in methods, devices, sessions, consents, identity profiles and the traits you protected, projects and edit history, your AI shoot requests, your render jobs, subscriptions, purchases and credit balances, safety decisions on your requests, your support conversations, your notifications, your original files, working copies you made, the watermarked previews you were shown, and every final you unlocked. A plain-language manifest inside the archive describes each file.

Three things are deliberately withheld, and the manifest states each one and why:

• Credentials — session tokens, recovery codes, push tokens. An archive gets saved to a laptop and mailed around; a live token inside one is a token in the wild.
• Other people — records that identify another account appear without that person's identifier. Your consent to export your data is not their consent to disclose theirs.
• Unwatermarked masters you never unlocked — these are listed in the inventory with the reason stated, but the file is not included. Otherwise "export my data" would be a way to take a paid final for free.

Also withheld: the key behind the forensic watermark, because publishing it would remove that protection for everybody; and raw safety-classifier scores, because they are a map for evading the safety system.

You can build up to three archives a day. Each one is available for seven days and is downloaded through a link that lives minutes.

10. Your choices

• Turn media processing off. If you decline media-processing consent, photo previews, AI shoot generation and video ingest all stop. This is a real block in the code, not a preference: the check sits in the services, so a new feature cannot forget it.
• Revoke an identity profile. The profile is marked revoked immediately and can no longer be used to generate anything, and a deletion task is created for it.
• Withdraw a consent. A withdrawal is a new dated record. The latest one applies.
• Export and delete, as above.

If you are in a place whose law gives you further rights — correction, restriction, objection, portability, or a complaint to a regulator — write to us at the address in section 13 and we will answer. We would rather tell you plainly that these requests are handled by people reading email than imply an automated rights portal that does not exist.

11. Children

This app is for adults. It is not directed to children, and you should not use it if you are under 18.

We do not verify your age. When you sign in, the account is recorded as an adult account on the strength of your using it. The only place age is enforced is the creation of a reusable identity profile, which is refused unless the account is recorded as adult. We are telling you this because an age gate you cannot see is not a protection you can rely on.

We do not knowingly collect information from children. If we learn that an account belongs to someone under 18, we will delete it and its media. If you believe a child has used this app, write to us at the address in section 13.

12. Photographs of other people

If a photograph shows someone other than you, you need that person's agreement before you process it here. Section 3 of the terms sets out that rule and it binds you regardless of what the app can check.

What the app actually does about it: the safety system blocks certain requests that involve another identifiable person outright — impersonation, sexual content depicting someone else, and content aimed at harassing a real person. It does not ask you to record that person's agreement and there is no consent you can record that would unblock a request. An earlier version of this policy said the app records a separate third-party-subject consent and that the safety system requires it; a value for that consent exists in our data model but nothing in the service ever reads it, so the sentence has been removed rather than left standing as a protection you could rely on.

13. Contact

Write to support@example-tbd.com, or open a ticket from Contact support in the app. The service is operated by TBD Holdings LLC.

14. Changes

Consent records store the version of this policy they were given against, so a change to this document does not silently reinterpret an agreement you made earlier. If we change something material — in particular, if a photograph of you starts being sent to an outside AI provider, or a named sub-processor list replaces section 5 — we will raise the version and record fresh consent where consent is what permits the processing.

15. What this policy does not yet cover

Stated here rather than papered over:

• No named sub-processors. No AI provider, email provider or hosting provider has been contracted. Section 5 describes categories because naming a company we have not engaged would be untrue.
• No international transfer statement. Where processing physically happens depends on the hosting decision, which is not final. We will not state a transfer mechanism we have not put in place.
• No data protection officer or EU/UK representative is appointed.
• No retention schedule for support conversations. Media and previews have the clocks in section 7. Support threads and their attachments do not yet have one; you can delete an attachment from your own thread at any time.
• Location metadata inside your originals is not removed. Section 1 says so in full. Your original file is stored exactly as you gave it to us, and a copy of your data that you export contains those originals, so both can carry a GPS fix your camera wrote. Rendered copies carry no metadata, and nothing carrying a photograph leaves our servers.
• A generated shoot is not conditioned on your identity profile. Sections 1 and 4 say so in full. The guided captures are stored but are not used by the AI photoshoot in this release, and a generated frame is not a picture of you.
• No third-party-subject consent is enforced. Section 12 says so in full. The rule in the terms binds you; the app does not check it, and the safety system blocks rather than asks.
• Records outside the media categories survive account deletion. Section 8 lists what the deletion job removes. Billing records, the audit trail, safety decisions and support history are retained.