Privacy Policy

Version 2026-09-20.1 · effective September 20, 2026

A note on how this document was written. The real failure mode of a privacy policy is not bad drafting — it is saying something that is not true. Every statement below was written against the running system rather than against a template, and where a mechanism does not exist yet, this document says so instead of describing an intention.

Magic Ingredient LLC, an Indiana limited liability company, operates Lunar Canoe and is the controller of the personal data described here.

• Postal: Magic Ingredient LLC, 8245 E 96th St #1158, Indianapolis, IN 46256, United States
• Privacy, access, export and deletion requests: support@enginyyr.com
• EU/UK representative: none designated yet; we rely on the Article 27(2) GDPR exemption for occasional processing, and will appoint one — and update this line — before that exemption stops applying to us

Contents

1. The short version
2. What we collect
3. What we deliberately do not collect
4. Why we process it, and on what legal basis
5. If you report content to us
6. Who else sees it: sub-processors
7. Where it goes: international transfers
8. How long we keep it
9. Deletion, and what "deleted" means here
10. Your rights
11. Security
12. Children
13. Automated decisions
14. Changes
15. Complaints

1. The short version

• Your prompts and your reference images are sent to Google. That is how a render happens. Google logs prompts and responses for up to 90 days for abuse monitoring, and that logging is not covered by customer-managed encryption keys. Section 5.
• Your director conversations are sent to Anthropic, our LLM provider for the conversational assistant. Section 5.
• If you generate a soundtrack, a silent render of the scenes you chose and your soundtrack prompt are sent to fal, which generates the audio. Section 6.
• Your files live in Cloudflare R2, keyed by the hash of their contents. Section 5.
• We do not run face recognition. We never compute or store a biometric identifier, and there is no "find other clips of this person". Section 3.
• Uploads are screened before they are usable against known child sexual abuse material and the categories in the Acceptable Use Policy. Section 3.
• We do not train on your content and we do not sell it.
• There are no cookies, and no analytics beyond a self-hosted, cookieless visit counter on the marketing site. One page of the marketing site, lunarcanoe.com/films, embeds a YouTube player and is the only place anything loads from a third party. See the Cookie Notice.
• Deleting a project erases the files behind it, after a 1-day window in which you can change your mind, and you get a receipt saying what went and what was kept. Section 9.
• Takes you moved on from expire after 30 days, and assembled exports after 90, always with notice first and always with a way to keep them. Section 8.
• If you report content to us, that report is permanent and cannot be edited or deleted, by you or by us. Section 5.

2. What we collect

Account

Your email address; a password or the credential you sign in with; the version of the Terms you accepted and when; your spending limits; and records of enforcement actions on the account.

Storyboard content — the things you write

Project names; per-scene intents (subject, action, camera, lighting, style, ambiance, notes); project- and group-level style; provider and model choices; durations, aspect ratios, seeds and negative prompts; and the ordering, grouping and seam structure of your storyboard.

Every change to a storyboard is written to an append-only command log that records who made it (you, or the director agent acting on a proposal you accepted), what changed, and when. The log stores the change payload — which means it stores the text you wrote. It exists so that undo works and so that "who did this" is answerable.

Assets — the files you upload and the files we make

Uploaded images (including images that show people), generated video clips, generated stills, frames extracted from clips, and assembled exports. For each we store the bytes, the SHA-256 of the bytes, the filename you uploaded it under, its kind and provenance, and its dimensions and duration where we can read them.

Images you upload may contain personal data of other people. Under the Acceptable Use Policy you may only upload an image of a real person if it is you or you have their permission.

Not built yet: we intend to ask you to affirm that at the point of upload and to store the affirmation — the answer, the version of the text, your account id and a timestamp — against the file, in a record that outlives the file. That is specified but not implemented, so no consent record is captured for uploads made today.

Generation records

Each render creates an attempt whose input snapshot is immutable: the compiled prompt actually sent to the provider, the hashes of the attached assets, the provider and model, the parameters and seed, the provider's operation id, the cost, timing, and any error. Attempt records are how spend is computed and how a result is reproduced, so they are not editable.

Generating a soundtrack creates a similar record: the soundtrack prompt and negative prompt, the first and last scene of the run, the seed, the settings of the render sent to the provider, the provider's operation id, the cost, and any error.

Director conversations

The messages you send the director, the assistant's replies, the tool activity summaries, and the command batches it proposed and whether you accepted them. Each thread maps to a session in our agent runtime, keyed by a pseudonymous account identifier rather than your email.

Payments

Payments are processed by Stripe, Inc.. We hold the transaction metadata we need for accounting — amount, currency, date, last four digits, the processor's identifiers — and we never hold your full card number: you enter it on the processor's pages, not ours.

Operational logs

Request logs, job records, errors, and the correlation identifier we thread through a command, an attempt, a job, a provider operation and an export.

We deliberately keep sensitive material out of logs: prompts, media bytes, tokens, credentials, storage keys, presigned URLs and agent tool payloads are never written to logs at normal levels. Provider errors are reduced to an operation name and an error code.

Waitlist

If you ask for an invite before signups open, we hold the email address you sent and anything you chose to write in the message, and we use it to send you an invite and occasional build notes. Resend

3. What we deliberately do not collect

These are architectural commitments, not intentions:

• No face geometry, face templates or face embeddings. We pass an uploaded image through to a model provider and we store the image. We do not compute a biometric identifier from it, we do not store one, and we do not match faces across uploads. There is no "find other clips of this person" feature and there will not be one. This is an architectural commitment that holds for anything we build later: automated safety checking, when we add it, will be limited to "is a face present" and "does this appear to depict a minor" — never "who is this" — and any vendor will be contractually barred from retaining a biometric template.
• Screening is not identification. Every upload is checked against known child sexual abuse material by hash, and classified for the categories in the Acceptable Use Policy, before it can be used. What those checks answer is "does this match known illegal material" and "does this fall in a prohibited category" — never "who is this". No face is matched across uploads and no biometric template is retained by us or, contractually, by any vendor.
• We still do not search your content proactively beyond that screening. We act on reports — US law imposes a reporting duty on what we actually know about, not a duty to search (18 U.S.C. § 2258A(f)). The model providers run their own safety filters on every request, but those are theirs, not ours.
• No advertising, no tracking pixels, no third-party analytics. The marketing site counts visits with a self-hosted, cookieless tool on our own domain that stores no IP addresses and builds no cross-site profile; the application has no analytics at all. The one exception to "nothing from a third party" is lunarcanoe.com/films, which embeds a YouTube player: Google receives your IP address and user agent when that page loads, and we receive nothing back and cannot tell who watched what. See the Cookie Notice.
• No cookies set by us. See the Cookie Notice.
• No training on your content, by us or, under our provider terms, by our providers on our behalf.
• No sale or sharing of personal data for money or for cross-context behavioural advertising.
• No public surface. There is no gallery, no discovery feed and no public profile. Your projects are private.

4. Why we process it, and on what legal basis

An image that shows an identifiable person is personal data about that person. We do not process it through any technical means intended to uniquely identify them, which is the line that would make it special-category data; see section 3.

5. If you report content to us

Anyone can file a content complaint at lunarcanoe.com/report without an account. This section is about the people who do that, not about account holders, and it is here because a complaint is one of the most sensitive things this service holds.

What a complaint stores

Everything below is written down at the moment you file, exactly as you sent it:

We do not verify any of it before acting, and that is deliberate: demanding proof of identity from someone reporting their own intimate images is its own harm.

What happens to it

• The notice as filed is immutable. The database refuses to change it. Only the workflow around it — triage state, resolution, when it was closed — moves.
• A complaint cannot be deleted. Not by you, not by us. The database refuses that too. The log is the evidence that the process was followed, and a log we could edit would be worth nothing.
• Removal receipts and the moderation log are also append-only, hold no foreign keys, and deliberately outlive the file, the complaint and the account they describe. A receipt records what was removed, its content hash, whether the storage delete and the cache purge confirmed, and who did it.
• There is no public read-back. Nothing returns a complaint to an unauthenticated caller, because that would leak your contact details and a description of intimate imagery to anyone who guessed a reference.
• Who can see it: the operator, through a separately credentialled administrative interface. Not the account you reported.
• We do not tell the reported account who you are.

Retention

Indefinitely, by design. We cannot offer you deletion or correction of a filed complaint, and we would be misleading you if we implied otherwise: the tables enforce it in the database. If you have a rights request about a complaint you filed, write to support@enginyyr.com and we will explain what we can and cannot do rather than quietly failing.

One honest limitation

The rate limiting protecting the complaint form is per server process and held in memory — it is not a deployment-wide ceiling, and it resets when the process restarts. It bounds one process's memory and database growth. If the form is ever unreachable, email support@enginyyr.com, which is always available and is named first on the published page.

6. Who else sees it: sub-processors

In use today

Our conversational agent runtime (grove-core) runs on our own infrastructure alongside the application; it is not a third party. It stores director session messages and a rolling summary, keyed by a pseudonymous account identifier.

Planned, and not in use yet

This list is empty today. Payments (Stripe, Inc.) and transactional email (Resend) moved out of it and into the table above when they went live, as upload screening did before them.

We will update this table before adding a sub-processor, not after. Write to support@enginyyr.com to be told when it changes.

We also disclose personal data where we must: to law enforcement or a regulator under a legally binding order; to NCMEC where US law requires a report; to professional advisers under confidentiality; and to an acquirer in a merger or sale, under equivalent obligations.

7. Where it goes: international transfers

We are a US company and our infrastructure is in the United States.

Generation runs on Google Cloud, in us-central1 for Veo 3.1 and image generation, and Google's global endpoint for Gemini Omni Flash. Because one of the models we use is served from Google's global endpoint, we cannot promise that every generation request is processed only in the United States, and we do not.

Soundtrack generation runs on fal. fal is based in the United States and says that it processes and stores data on servers in the United States and other countries, so we cannot promise that a soundtrack request is processed only in the United States.

Object storage is Cloudflare R2; the bucket's location is North America (Cloudflare's ENAM location hint). Cloudflare is a global network and objects may be served from, and cached at, locations near the requester.

If you are in the EEA, the UK or Switzerland, using the Service transfers your data to the United States and potentially elsewhere. Where required, transfers rely on the European Commission's Standard Contractual Clauses and the UK Addendum as incorporated into our providers' terms.

Two provider restrictions apply specifically to the EEA, Switzerland and the UK and are worth knowing because they change what the product will do for you: image-to-video generation is restricted to adult-only person generation, and one of our models will not edit images containing minors in those regions at all.

8. How long we keep it

Our retention schedule is published in full at lunarcanoe.com/retention. It is published before it is enforced, deliberately: expiring something on a policy you could read is fair, and deleting it later under a rule invented afterwards is not.

Nothing expires without notice. You get one notice 14 days and again 3 days before anything goes, listing exactly what is affected, and every notice carries a keep this button that takes the file off the schedule indefinitely. Nothing can expire that you were not told about: the rule is enforced in the query, not by a procedure someone has to remember.

Anything you had before the schedule was published is exempt from it. Retention starts from publication, not retroactively.

You can see all of this. The Service shows what you are holding, what is expiring, and when.

9. Deletion, and what "deleted" means here

This is the section most likely to differ from what you expect from a service like this, so it is written plainly and without softening.

What you can do

• Delete a project, including the files behind it. The project stops accepting new work at once and is destroyed after 1 day, which is there so a mis-click does not cost you work you paid for. You can cancel at any point in that window and nothing will have changed.
• Close your account. Every project goes, then the account row is reduced to a tombstone. The window is 7 days, and you can cancel throughout. You have to type your own email address to confirm.
• Take your work with you first. One archive holding every project, every file under its original name, your director conversations, and your spend history. Ask for it before you close the account; the link expires, and it stops working when the account does, because a live download of everything we just promised to delete would make the promise worthless.
• Ask instead. If you would rather not use the buttons, write to support@enginyyr.com and we will do it. We answer within one month (section 10).

What deletion actually does

Every deletion — a project, an account, or something expiring on the schedule — runs through the same path and produces the same receipt:

1. The database rows are deleted outright, not hidden.
2. The files are deleted from object storage. Cloudflare R2 deletes are strongly consistent, and R2 keeps no object versions, so a delete is a delete.
3. The edge cache is purged, because deleting the object is not enough on its own.
4. The corresponding sessions in our agent runtime are disposed of.
5. A receipt is written and shown to you: what was deleted and how much of it, how many files were erased, what was kept and why. If a single file could not be erased, the receipt says so and the deletion is not reported as finished — it is retried until it is.

One thing that surprises people. Files are stored under a hash of their contents, so two identical files are one stored object. If you delete a project containing a file that another of your projects — or another person's account — also holds byte-for-byte, your record of it goes and the stored file stays until the last reference to it does. The receipt tells you when this happened and how many files it affected. We would rather explain this than quietly leave you with a wrong impression of what "deleted" meant.

Backups

Removed from live systems immediately: the rows are gone, the files are gone, the cache is purged.

Encrypted database backups are separate and age out on their own schedule of 30 days. They are never used to restore an individual deleted record, and if we ever restore from one, every deletion recorded since is re-applied to it. Until a backup ages out, the data in it is isolated from any further use. We do not make a claim about Cloudflare's backups: Cloudflare publishes no backup-purge commitment for R2, so it is not ours to promise.

What will never be deleted

• complaints, removal receipts and the moderation log (section 5) — append-only in the database, and not deletable by us either;
• financial records: for each charge, the provider, model, cost and time. They contain no prompt, no image and no video, and they survive account closure as an explicit exception to erasure because tax and chargeback law requires it;
• the record that you asked to be forgotten, and what we did about it;
• anything we are legally required to preserve, or that is under a legal hold. Where a hold stops part of a deletion, the receipt names it and says why rather than passing over it in silence.

Where we hold something we cannot delete, we stop using it for anything other than the reason we are required to keep it, and we delete it as soon as that reason ends.

The one path that erases across every account

Content removed under a content complaint is deleted more widely than anything you can trigger yourself:

1. The file is deleted from object storage and the edge cache is purged.
2. Every byte-identical copy across all accounts goes with it, because files are stored under the hash of their contents. A re-encode or a crop has different bytes and is not covered.
3. If either step fails it is retried until it confirms. Until both confirm the removal counts as unfinished and the complaint cannot be closed.
4. The content hash is held so exactly those bytes cannot be uploaded again by anyone.
5. A receipt is written to a log that cannot be edited or deleted.

10. Your rights

Wherever you are, you can ask us to:

• tell you what we hold about you and give you a copy;
• correct anything inaccurate;
• delete your data (subject to sections 8 and 9);
• export your projects and Output in a usable form;
• object to or restrict processing based on legitimate interests;
• withdraw consent where consent is the basis, without affecting what came before.

The first, third and fourth are buttons in the Service rather than a request you have to make: it lists every category of personal data we hold and where each one lives, it builds you an archive of everything, and it deletes projects and closes accounts. Using them does not stop you writing to us instead.

Email support@enginyyr.com. We answer within one month. If a request is genuinely complex we may extend by up to two further months, and we will tell you why inside the first month. We do not charge for this, and we do not treat you differently for asking.

If you are depicted in content someone else uploaded, you do not need an account to ask us to remove it: file at lunarcanoe.com/report. See sections 4 and 11 of the Acceptable Use Policy.

Three limits we would rather state than have you discover. A complaint you filed cannot be deleted or corrected (section 5). Financial records survive account closure for as long as tax law requires, though they hold no prompt, image or video (section 9). And a file whose exact bytes someone else also holds keeps existing until the last reference to it goes — your record of it is deleted either way, and the receipt tells you when this happened (section 9).

11. Security

Traffic between your browser and us, and between us and every provider, is encrypted in transit. Access to production systems and production data is limited to the operator of the Service. Asset storage keys are the hash of the file's contents and are not guessable from anything about you; media URLs handed to your browser are short-lived signed URLs. Prompts, credentials, storage keys and media bytes are kept out of logs.

We are a very small company. We hold no independent security certification — no SOC 2, no ISO 27001 — and we are not going to imply otherwise. If you need one, we are not the right supplier yet.

If you find a vulnerability, write to support@enginyyr.com. We will not pursue you for good-faith research.

12. Children

The Service is for people aged 18 and over. We do not knowingly collect personal data from anyone younger. If you believe a child has an account, write to support@enginyyr.com and we will delete it.

Separately, and more importantly: do not upload images of children. See section 2 of the Acceptable Use Policy. We do not scan for them; we act on reports, and a child-safety report carries our fastest removal clock.

13. Automated decisions

We do not profile you, and we make no automated decision that produces a legal or similarly significant effect on you. For completeness, these are every automated decision in the Service:

• Spending caps. A render that would take you over your daily or monthly cap is refused before it is submitted. You set the caps.
• Quarantined content hashes. An upload whose bytes exactly match content removed under a complaint is refused. An operator can lift that hold.
• Account sanctions. A restriction, suspension or ban applied by an operator is then enforced automatically on every request. three upheld copyright complaints suspend an account without a further human step.
• Rate limiting on the public complaint form.
• Model provider safety filters. Google's filters can refuse a request or withhold its output. That decision is the provider's and we cannot override it.

We do not run any automated content classification of our own — no upload scanning, no age estimation, no face detection. If we add it, this section changes first.

Where an automated outcome restricts your account, you can ask a human to look at it: reply to the notice or write to support@enginyyr.com.

14. Changes

We will post any change here, bump the version, and record it in CHANGELOG.md. For a material change we will email you at least 30 beforehand.

15. Complaints

Write to support@enginyyr.com first; we would rather fix it. If you are in the EEA, the UK or Switzerland you also have the right to complain to your local data protection authority. If you are in California, you may have rights under the CCPA as amended; we do not sell or share personal data as those terms are defined there.

Attribution: the framing of the "who can access your data" and sub-processor sections is adapted from the 37signals policies (specifically the "Uptime, Security, and Privacy" section of their Terms of Service), © 37signals LLC, used under CC BY 4.0. The deletion, complaint-data and retention sections are original and were written against this repository's code and against docs/07-complaint-intake.md. Sources and licences are recorded in README.md alongside these documents.