Privacy

1 · Who we are, and who is responsible for what

LOTGEN is operated by Ascended Entertainment LLC, 10585 Medicine Bow St, Las Vegas, NV 89183, United States.

For the things you put into a workspace, briefs, reference images, product pages, scripts, provider keys and the assets your providers return. The workspace owner is the controller and LOTGEN is the processor. We hold and process that material to run the workspace, on the owner's instructions.

For account data. Your email address, your name, sign-in events and billing, LOTGEN is the controller.

2 · What we hold

Account. Your email address, display name, which method you sign in with, and one row per session carrying the browser's user-agent string and when it was last used. Signing in with Google asks Google for openid email profile and we keep the email address and name only. The profile picture and everything else in that response is read and dropped, and that sign-in keeps no Google token at all.

Sign-in attempts. The sign-in door is rate-limited, and the limit is counted in the database rather than in one server's memory because more than one instance can be up. So each attempt writes two rows: one keyed by the address, one keyed by the IP address the request came from. They carry nothing else, and the same code that writes them deletes rows older than an hour.

Workspace. Members and invitations, spend caps, model settings, your lots, shots and takes with the prompts that made them, what each take cost, and review links with the decisions left on them — which are set out in section 5, because they are the one place a person who has no account leaves something behind.

Agent connections. When an agent such as Claude connects over MCP, we record which client it was, which workspace it was allowed into, who allowed it, and when it was last used. The tokens themselves are stored hashed and can be revoked from the MCP page in the app.

Provider keys. Sealed at rest, decrypted only inside the worker that submits your jobs, and never returned by any API. The interface shows a hint of the first and last few characters and nothing more.

A request for an invitation. If you fill in the form at /request we hold the address, the name you gave, which of four descriptions you chose, which platforms you said you already pay for, and, where the link you arrived by carried them, its campaign tags. One row per address: asking again updates it. It creates no account and no session, and the only things done with it are the receipt, a note to whoever runs the beta, and the reply. There is no automatic sweep of these rows; write to support@lotgen.ai and yours is deleted.

A connected Google Drive. Only if somebody in the workspace connects one. We then hold that person's Google refresh token, sealed the same way a provider key is; the Google account's email address; the scopes Google actually granted, which are not always the ones we asked for; the id of the folder we deliver into; and a row for each transfer saying which files went and how each one fared.

3 · Where your jobs go

A render is sent to the provider the workspace chose, on that workspace's own key, carrying the prompt and any reference images the shot needs. There is no house key to fall back on: a workspace with no key for a platform submits nothing to it. Some passes hand the provider a link to a file in our storage, signed for one hour, rather than uploading the bytes — an edit, an upscale or a lip-sync needs the take it is working from.

The platforms are Google, BytePlus ARK, fal, evolink, Kling, OpenAI, MiniMax, Black Forest Labs, Alibaba, ElevenLabs, Anthropic, xAI and Runway.

Each of these is your own vendor under your own agreement with them. LOTGEN holds no account with them on your behalf, and what they do with a submission is governed by their terms, not ours.

4 · Sub-processors, and your Google Drive

These are the services LOTGEN itself runs on.

• Google Cloud (United States, region us-central1): Cloud Run for the API, the render worker and the MCP server; Cloud SQL for the database; Secret Manager for our master key, for the individual data key that seals each provider key and each Drive token, for the database and mail credentials and for the Stripe webhook signing secret; and Cloud Storage for generated assets — one bucket we run, in the same region, with every object key namespaced by workspace.
• Vercel: the web application at lotgen.ai.
• Cloudflare: DNS for lotgen.ai.
• Stripe: subscription billing. Card details go to Stripe, never to us.
• Google Workspace: sign-in links and invitations are sent over SMTP from signin@lotgen.ai.
• Resend: the fallback mail transport. The code prefers the SMTP account above and uses Resend when no SMTP credentials are configured, so an address of yours can be handed to either one.
• Plausible Analytics (European Union): page views and a few named events on the public pages only, with no cookie and nothing that identifies you from one day to the next. Section 6 says exactly which pages and which events.
• Cal.com: only if you book a walkthrough. The booking page is theirs; the name, email and notes you type there go to Cal.com under our account and are governed by their terms. LOTGEN sends nothing to it on your behalf.

Beyond that list, workspace material leaves only where you send it, and today there is exactly one such destination: your own Google Drive. Connecting one is a person's own grant and it is off until somebody makes it. The scope we ask for is drive.file, which reaches only the files and folders we create or that you hand us with Google's picker, and we check what Google actually granted rather than assuming we got it. Sending a lot then streams the files from our storage into that Google account on our server — the browser never touches them — together with a manifest and the Article 50 declaration in section 10. Importing goes the other way: files you pick are copied from that account into the workspace. Disconnecting asks Google to forget the grant and destroys the data key that seals the stored token, in that order.

5 · Review links

A client opening a review link needs no account, and the link is the whole of the permission: anyone holding it can open that lot, until it is revoked or its expiry passes.

A verdict records four things — approve or change, the comment typed with it, the name typed into the name box, which can be left blank, and an id the browser mints for itself and keeps in local storage. That id is why a reviewer's second verdict supersedes their own first one rather than somebody else's: the typed name is free text on a page anyone with the URL can open, so it is a label rather than an identity. Clearing the browser mints a new id, and the person is a new reviewer.

The public review routes are rate-limited by IP address. That count is held in the server's memory, is written to no table, and does not survive the process. Nothing else about the person who opened the link is recorded.

6 · Analytics, cookies and browser storage

One analytics script, on the public pages only, and no advertising pixel. The pages a visitor reads without signing in load Plausible Analytics: the front page, pricing, the Academy, the developer page, the request form, the cost pages and the cost calculator, these legal pages, and the page checkout returns to. It sets no cookie and keeps nothing that identifies you from one day to the next. It reports page views, the campaign tags on the link you arrived by, and a handful of named events: a click on Get a workspace or on the walkthrough link, a checkout started or completed, an invitation requested, a lesson opened, a calculator spec run. An event carries which plan, which lesson or which spec and never who. It is not loaded inside the workspace and not loaded on a review link, where section 5 applies. There is no tag manager.

Four cookies, all ours, all functional. lotgen_session is your signed-in session. The other three exist only for the length of a redirect and carry the state of a round trip: lotgen_oauth for signing in with Google, lotgen_drive_oauth for connecting a Drive, and lotgen_oauth_rid for an agent's authorisation request while you decide whether to allow it.

Your browser also keeps a few things locally, which never reach us as such: the lots you opened recently, one or two view preferences, the reviewer id and name described in section 5, the campaign tags on the link you arrived by (for the length of the tab, so the request form can say where you came from), and — if you sign in by pasting a workspace API key rather than by email — that key, until you sign out.

One third-party script, and only if you ask for it. Choosing a Drive folder or file loads Google's picker from apis.google.com at the moment you press the button. Nothing loads it otherwise.

7 · Retention

A discarded take and an archived lot are kept for 15 days and then deleted — an hourly sweep in the render worker removes the files from storage first and the rows after, so a crash between the two leaves a row pointing at a file that is already gone rather than a file nothing can name. A workspace can extend any one lot, once or more, up to 30 days from the day it was archived, measured from that day and not from today. Active lots and the takes you kept stay as long as the workspace does.

Usage is not a separate record. The Usage page and the spend cap are built from the same job rows as your takes, so a discarded take's spend leaves Usage when the take is deleted, and deleting a lot takes its takes out of Usage at once. What outlives them is what Stripe holds for the subscription — invoices and the card — and whatever your own providers keep on their side of a submission; neither is ours to delete.

8 · Deletion

Removing a provider key, deleting a lot and deleting a workspace all take effect immediately, there is no undo, and nothing in the product brings any of it back. There is no trash and no grace period; archiving is the window, and deleting is the door with none.

What that means for a stored credential has two cases, and we would rather write both down than let the stronger one stand for the pair.

• A key sealed with a data key of its own — every key saved since we moved to per-key encryption. That data key lives outside the database, in Secret Manager, and removing the key destroys it in the same request. What is left, in the database and in any backup of it, is ciphertext with no key anywhere that opens it.
• A key saved before that change was sealed under a single master key we hold rather than one of its own. On 8 September 2026 we moved every remaining key of that kind onto a data key of its own, so this case is now empty and no stored credential is in it. One thing does survive the move: a database backup taken before that date still holds the older ciphertext, which the master key can open, until that backup ages out. The system counts these rows every time it shreds, and the count is now zero.

Two failures are possible and neither is silent. If Secret Manager refuses to destroy a data key, the row still goes, the refusal is recorded and alerted, and an operator finishes it by hand. And if storage refuses a file: deleting a workspace stops before touching any rows and answers an error you can retry, while deleting a lot proceeds and records the file it could not remove — so a stray object can outlive the rows that named it, which we find with a sweep we run by hand rather than on a schedule.

Deleting a workspace does three things in one request, in this order: destroys its keys, deletes every object stored under its own prefix, and removes its rows. The order is the design — a workspace that cannot render is a state somebody can see and ask about, and files nothing can name are not.

9 · Your rights, and how to reach us

Write to support@lotgen.ai. We will export or delete your account data on request; export inside the app is per lot, from the editor, so anything wider than that we do by hand. For material inside a workspace, the workspace owner is the controller and handles those requests; we act on their instructions.

10 · AI transparency

Everything this product makes is generated by an AI model, and every pack we deliver says so in machine-readable form: the export zip, a takes export, the JSON an agent gets back and a delivery into Drive each carry the same EU AI Act Article 50 declaration, written once in one module so two deliveries cannot disagree about what was disclosed.

Two downloads do not carry it, and naming them is cheaper than letting the word “every” cover them: the bare timeline.xml sequence, which is an edit list with no media in it, and a signed link to a single file, which is the file itself.

We make no C2PA claim: the exports are not C2PA-signed and we do not describe them as provenance-verified.