Your script never trains us.
Your contract never leaves you.

No. Not now, not ever, not by default. We don't fine-tune any model on user content. Every AI inference provider in our infrastructure — Anthropic for text, and our image generation stack of Nano Banana Pro, Flux 2 Pro, and DALL-E 3 — is contractually prohibited from training on what we send them under their respective standard API policies. We've also configured Zero Data Retention with Anthropic, and we configure ZDR on the image side wherever the vendor offers it for our account.

If we ever wanted to change this, it would require an explicit, opt-in, separately-consented program. You would not be opted in by default, by continuing to use the platform, or by accepting any update to the terms.

Most of OGF AI uses Anthropic's Claude for text. The Pitch Deck Builder also generates background images and identity-locked character imagery for your slides — and for that, we route through a stack of three image providers: Nano Banana Pro as primary, Flux 2 Pro as failover, and DALL-E 3 as backstop. A given image render goes through one of the three depending on per-request availability. This is how we keep your characters visually consistent across every slide even when one vendor has a bad day.

The image prompts we send to any of these vendors are derived from your Style Bible, which means they reference your characters, scenes, and world. Each vendor's standard API policy prohibits training on what we send. Where ZDR is available for our account on a vendor, we've configured it. If you'd rather not have IP-derived image prompts go to any of these vendors, you can use the Pitch Deck Builder without generating images, or skip that tool entirely.

It's protected with the same architecture as your own work — encrypted, locked to your account, never used for training, never shared. We don't separately contact, market to, or build profiles of the people whose information you enter. Their data is bound to your project and to your account.

You agree at signup that you have the right to enter that information — for example, because you've discussed the contract with the person, because they're a collaborator who's expecting to receive a contract, or because applicable law permits you to. If they later contact you about their data, you can ask us to help. If they contact us directly, we'll route the request through you.

For minor children specifically (in the Minor Performer Release flow), you're confirming that you've obtained appropriate parent or guardian authorization. We retain minor information for the shortest period consistent with your production need.

Not in routine operation, no. There is no internal dashboard, search tool, or interface that gives our team bulk access to user content. The only path to your content is a support ticket you initiated, where access is granted only for the specific request, logged, and revoked when the ticket closes.

We're also small. The honest version: yes, technically, the founder has root access to the database — that's true of every early-stage SaaS company in existence. What we commit to is that we don't use it. We log access. We document our internal policy. And as we grow, we add the structural controls that make even technical access genuinely impossible without an audit trail.

The buyer is bound by the same terms in place at the time of transition. They cannot weaken protections without giving you 30 days' notice and an explicit opt-in — not a forced acceptance. Before the transition takes effect, you'll have the option to export everything and delete your account.

This is written into our binding Terms of Use. It also makes OGF a more attractive acquisition target, because a clean privacy posture is worth more in a sale than a permissive one.

It's processed in-session for whatever you asked for, then stored in your project vault under the same protections as everything else. We don't study it, extract clause patterns from it, or aggregate it with other users' contracts to "improve the platform."

We've thought about whether to build an opt-in program where filmmakers (and their attorneys) could choose to contribute redlines to help improve the Contract Builder for everyone — with explicit consent, compensation, and a right to withdraw. It's an idea we've architected for but haven't built. If we ever do, you'll know — and your existing redlines stay outside the program unless you opt them in.

The kind that describes how the platform works for you, not what's inside your project. Examples: which tool you opened first, how long generation took, where you dropped off in intake (the question identifier, not your answer), whether you completed the Securities Compliance Gate before generating an investor agreement (yes/no, not the gate's contents), how many tools you've used on this project.

This is the data that lets us see the "life of a project" — where filmmakers came in, how the platform moved them forward, where they got stuck. It's the foundation of our product decisions and our valuation. None of it reveals what's inside your script. You can request a full copy of all metadata associated with your account at any time.

Good question. That's a Phase 4 feature — not yet built. When we build it, it will query a pre-computed aggregates table that enforces a minimum of 10 users per data point. Real-time per-user queries against your project to make outward-facing recommendations are prohibited. The aggregation rule is enforced at the database layer, not just in policy.

Yes to both. Export your full project vault as a downloadable ZIP archive any time, free of charge. Delete a project, and after a 30-day grace period, it's gone from production and from backups. Close your account, and after the same grace period, your content is permanently purged. Your aggregate metadata is anonymized at account closure — your user identifier is rotated to a non-reversible hash so the aggregate signal of past use is preserved while no individual record can be traced back to you.

Our Film School and Enterprise tiers support multiple users under one institutional account, with tenant-aware row-level security so one student can't read another student's projects. Institutional administrators can see organization-level usage metadata (which tools are used most, aggregate engagement) but not the contents of individual users' projects unless those users explicitly grant access.

For students under 18: the institution represents at signup that all student users are 18+, OR that the institution has obtained appropriate consent under applicable education-data law (FERPA in the United States). We don't directly verify student ages or parental consent — the institution is responsible for that. Talk to us before onboarding student users under 18.

You'll hear from us within 72 hours of confirmation, by email, with what happened, what data was involved, what we're doing about it, what we recommend you do, and how to reach us with questions. If the incident affected third-party data you'd entered, we'll work with you on appropriate notification to those people. We'll also notify regulators where required by law.

Email security@getogf.ai with a description of the issue. We commit to acknowledging within 48 hours and working with you in good faith. We don't currently run a paid bug bounty (it's on the roadmap), but we'll publicly credit responsible disclosures with permission.