T6FV Privacy Policy

THE 6-FIGURE VIDEOGRAPHER LTD. Mississauga, Ontario, Canada

Last Updated: October 12, 2026

Effective: November 11, 2026. Until then, the previous version of this policy applies. It is available on request (Section 12).

This Privacy Policy explains what personal information THE 6-FIGURE VIDEOGRAPHER LTD. ("T6FV", "we", "us") collects through the T6FV ecosystem — the T6FV / T6FV.io video production planning app for iOS, Android, macOS, and Windows, the t6fv.io website and hosted share pages, and the community features inside the app (together, the "Services") — how we use it, who we share it with, and the rights you have. It forms part of our Terms of Use.

The short version: the app is built local-first. Your footage and field audio, your mail and the password or sign-in that opens your mailbox, your device's own position and your AI conversations stay on your device on every plan; on a plan without a cloud library, so do your projects, clients, finances and contacts. There is one way you can send your work to an AI company from inside the app, and only you can open it. On a Mac or a Windows PC you can connect an AI app you have installed, such as Claude, Cursor or Codex, so that it can read and change the work you choose. You can also chat in the app on an API key of your own from Anthropic, OpenAI or Google. What that AI reads goes from your computer to the company behind the app or the key, under your agreement with that company, and never through us. We cannot see or control what that company does with it (Section 5). The one exception for your footage, photos and field recordings is small editing copies — low-resolution proxies of your video and previews of your photos and recorded sound — that you choose to share for a production through your T6FV Drive, so your other devices can keep editing. When you join somebody's recording session from the app, though, what your device records for it goes over the local network straight to that session's main device — which may be theirs rather than yours — and never passes through us. While it is joined, it also sends that device how loud its microphone is — a level, never the sound. A guest who records for a session from a recording link in a web browser is the exception: what they record is encrypted in their browser, with a key we never receive, and waits in our storage until the host's device collects it. A guest who joins a live show from a link in a web browser is not an exception: their camera and microphone go straight from their browser to the host's and never pass through us; we only pass along the first handshake, sealed so that we cannot read it. The pictures and video you put on the screens of a Virtual Studio show go over your Wi-Fi from your device to the screens that join it, and never to us. We only receive what you deliberately send to a cloud feature — your account details, your subscription status, content you choose to publish or share, files you put on T6FV Drive, and, where your plan includes one, the cloud library described in Section 3. If you join a company's workspace on T6FV, the binders in your account become the company's: its Owner and its Admin seats can open them, its Owner is paid the card payments on your invoices and sees their figures, and when your seat ends the binders stay with the company and the app clears your account from the devices that held the seat (Section 3, "Company workspaces"). If you log time on a task, the hours you record are seen by you, by the people who can edit the binder's brief, and, as a total for that task, by the others assigned to it; the app records time only when someone starts a timer or enters it, never by watching what you do. Note that a saved location, like a scouted site, is a planning record rather than a position: it travels with the rest of them. Two questions about a place you have saved are answered by our servers, and neither is kept: which time zone it is in, so that its sun times are the place's own, for which the app sends its coordinates rounded to about a kilometer; and, when someone opens a client link you have published, the forecast for its shoot days in the next ten days, for which the page sends each day's date and place rounded to about eleven kilometers, and our servers ask Apple Weather. The settings of a mailbox you connect travel with them too — its address, server details and any signature you add, never its password and never your mail — to your own devices only, so that each of them can list it. So do your app preferences — your favorite tools, your notification and backup choices, your theme and language, your desk background, and the brushes you save in the Graphics Editor — again to your own devices only, so that each of them is set up the way you left the last. So does what you record about the hard drives you add — each drive's name, notes, tags and photo, the folders on it you have linked to your productions, what identifies the volume, and a summary of its last scan that includes the names of the folders at the top of the drive, often a client's or a job's name — again to your own devices only, so that a drive you plug into another of them is recognized rather than added twice; the files on a drive, and the access the app holds to open one, never travel. So, unless you switch it off for a drive, does the listing of each drive's last scan — the name, size and date of every folder and file the scan reached, which can name clients, jobs and people, and the name of the device that scanned it — so that your other devices can search and browse a drive that is not plugged in; the files themselves still never travel. We run no analytics, no advertising, no tracking, we run no AI service of our own that receives your content, and we never sell your personal information or use your content to train AI models.

1. Who We Are and How to Reach Us

The organization responsible for your personal information is:

THE 6-FIGURE VIDEOGRAPHER LTD. Mississauga, Ontario, Canada Privacy Officer: info@t6fv.com

Contact our Privacy Officer for any question, access request, correction request, complaint, or concern under this policy.

2. What Stays on Your Device (Most Things)

The app stores your working data locally, in the app's own storage on your device. We do not automatically sync, upload, mirror, or back up this data, and we cannot see or recover it — with one exception, described in Section 3 under "Cloud library": some subscription plans include one, and while you hold such a plan your planning records — and the pictures, audio and files kept with them — are copied to our servers so your own devices can read the same work, and so that people you invite to a binder can read the parts of it you grant them. Locally stored data includes:

• Projects and binders: tasks, briefs, productions, shoot days, call sheets, schedules, scenes, shots, takes, and deliverables;
• Client records, contact lists, crew and cast lists (including anything you import from your device's address book);
• Financial data: pricing, quotes, budgets, invoices, and payment records you keep in the app;
• Captured footage and field audio takes — what the camera and recording tools capture stays on the device that shot it, including video, multicam, timelapse and stop-motion recordings and the takes from the audio field recorder — except small editing copies, low-resolution proxies of your video and previews of your photos and recorded sound, that you choose to share for a production through your T6FV Drive, so your other devices can keep editing, as Section 3 describes under "Editing copies". A picture you then file into a project — a still you keep as a reference, a frame you drop into a mood board — travels with the record that points at it if your plan includes a cloud library, as described in Section 3. Where one of your devices operates another's camera, the footage travels between your own devices and does not pass through us. A recording session is different, because the device at the other end may not be yours. If you join someone's recording session — by scanning, or typing in, the code shown on a shoot's main device, on the same Wi-Fi — what your device records for that session is sent over the local network directly to the session's main device, which may belong to somebody else: a podcast host, a producer, whoever is running the shoot. It never passes through our servers. The main device lists your device under the name it goes by in the session and a random identifier the app keeps for your device, so that a device that rejoins is recognized rather than listed twice. Both are sent as soon as your device joins, so the name it starts with is the one your device already goes by — such as its model, or a computer's network name, which may include your own name — until you change it on the join screen. While your device is joined to someone's recording session, it also sends that session's main device how loud its microphone is — a level, never the sound — while the tool you joined with is open, before a take starts and during it; the main device shows it as a meter beside your device, warns when it stays silent during a take, and does not save it. Each recording carries that name, what your device was recording as (a camera, a microphone, and so on), and what the main device needs to file it: the shot and take it was recorded for, when it started, how far your device's clock was from the main device's, its format and the camera settings it was recorded with, and, for a microphone, which input was used. The person running the session keeps what arrives as takes in their own project, like anything they recorded themselves: the recording on their device and, if their plan includes a cloud library, the take's record — when it was made and its clock readings, its length, format and settings, but not your device's name — in that library, as Section 3 describes. The recording itself never reaches us, and your device keeps its own copy. Running a session is the same arrangement the other way round: what the devices that join it record arrives on yours, and whatever it shows of other people is yours to look after under Section 3A. A guest you invite to record from a link in a web browser is different: what they record reaches you through our storage, as Section 3 describes under "Recording links for guests";
• Your email, if you connect a mailbox. The mail feature signs in to an email account you already hold, using an authorization or credentials you supply, which are kept in your device's own secure storage. They are never sent to us, and the app does not copy them to your other devices: each device signs in for itself. Messages, attachments and folder structure it downloads are cached on your device so you can read and search them, and are filed against your binders there. Your messages do not reach our servers, and we cannot read them — the mailbox cache is deliberately excluded from the cloud library, so a device that syncs your planning records does not carry your correspondence with it. Mail you send goes from your account through your provider, not through us. There are two exceptions, and you make both on purpose. If you save a message or an attachment into a binder, it becomes a project file like any other and follows the same rules as the rest of your project files, including travelling in a share or export link if you put it in one. And if you file a message against a job — the action that puts it on a binder's correspondence list — the app keeps a short record of which message it was so the list can still be drawn after the mailbox cache has been cleared: the sender, the subject, the date, and the opening line or so of the message. That record is a planning record, so on a plan with a cloud library it travels with the others. The body of the message, its attachments and the rest of your mail do not. The mailbox's settings are different, because they are what lets you connect a mailbox once rather than on every device, and on a plan with a cloud library they travel: its email address, the name your mail is sent under, its incoming and outgoing mail server names, ports and security, which provider it was set up for, whether sent mail is also copied to your Sent folder, whether filing a message also files it on the mail server, whether it signs in with a password or through your provider, the signature you add to your messages if you add one (one for your business, and any you set for a particular mailbox), and when it was connected and last changed. They go to your own devices only — never to anyone you share a binder with — and Section 3 says where they are held on the way. A mailbox that arrives on another device this way is signed out there until you sign in on that device once. The same settings are included in a .t6fv_vault backup you export, so a vault you give to somebody else tells them which mailboxes you connected and which servers they use, though not how to open them. Disconnecting a mailbox removes it from every one of your devices — its settings everywhere, including from the cloud library, and on each device its stored authorization and its local cache. Filing records you made stay with the jobs they were filed against;
• Scripts, notes, ideas, mood boards, storyboards, and generated documents (contracts, releases, and similar);
• Gear inventories, lighting diagrams, and tool settings — except the app-wide preferences listed in Section 3, such as your favorite tools, your theme, which notifications you get and the brushes you save in the Graphics Editor, which travel with the cloud library to your other devices;
• Your hard drives. The Hard Drives tool lists the drives you connect and scans them, so that you can find your work and back it up. The files on a drive are never sent to us, and neither is most of what the app keeps about them on the device: the search index it builds of a drive's contents, the record of files it has copied there, its transfers to and from a drive, the access your device has given it to open a drive, and any password you set for the backups it keeps on one. Two things are different. What you record about a drive itself is what lets a drive you plug into another of your computers be recognized there rather than added a second time: on a plan with a cloud library it travels to your own devices, as Section 3 describes under "Cloud library", and it includes a summary of the drive's last scan with the names of the folders at its top level. And the listing of a drive's last scan — every folder and file name the scan reached, with each one's size and date, which can name clients, jobs and people — travels to your own devices on such a plan too, with the name of the device that scanned it, so that you can search and browse the drive from another of your devices while it is not plugged in. Search and browse this drive from my other devices, in a drive's Edit drive sheet, keeps a drive's listing on the device that scanned it;
• Your location — the sun-tracking and location-scouting tools compute sun position on the device, and your device's own position is never transmitted to us or used to track you. A location you deliberately save is different: a scouted site you record, with whatever coordinates you attach to it, is a planning record like any other, so on a plan that includes the cloud library it travels with the rest of them (Section 3) and reaches anybody you have shared that binder with. The distinction is between where your phone is, which we never receive, and a place you have written down, which is yours to share. Two questions about a place you have written down are answered by our servers rather than on the device. Which time zone it is in: once you have accepted this version of the policy, the app sends the place's coordinates rounded to two decimal places (about a kilometer) to our servers, which answer with the zone's name, and the app keeps the answer on that device so that it does not ask again. And what the weather will be there: a client link you have published asks our servers, when someone opens it, for the forecast of its shoot days in the next ten days, sending each day's date and its place rounded to one decimal place (about eleven kilometers), and our servers put that question to Apple Weather. We do not store either question or log the place in it, and Apple receives only the rounded place and the date — no account, no name, and not the IP address of the person reading the page. The phone's own position is never among them;
• Your calendar — calendar sync writes events to a calendar you choose, using your device's calendar framework, and only ever touches events it created;
• A Virtual Studio show. When you run a show, your device sends the pictures and video you put on its screens, over your Wi-Fi, to the phones, tablets, TVs and browsers you let join with its code. They go from your device to theirs and never to us, and each screen is sent only what it shows. Your device remembers, on itself only, each screen that joined — a name, a key it rejoins with, its delay, and what it said about itself (its screen size, its platform and, for a browser, its user agent). None of that is synced, backed up or sent to us. The show itself is saved in the scene's Lighting Diagram, which travels with your binder like the rest of the diagram (Section 3);
• Being a screen in somebody's show. A device that joins somebody's Virtual Studio show receives the pictures and video that show puts on it, from the device running the show, over the Wi-Fi, and never through us. The app keeps them in its own storage so that a show survives a dropped connection, deletes what has gone unused for seven days, and deletes it at once when the show's operator ends it with "End and clear screens". It remembers the shows it joined — their names and their addresses on the Wi-Fi — so that it can rejoin them. No account is needed and nothing is sent to us. A web browser that joins keeps what it was sent in its own cache for up to twelve hours, and the operator's "End and clear screens" cannot clear a browser's cache;
• AI chats and AI connections — conversations with the on-device AI assistant are stored only on your device. On a Mac or a Windows PC, so is what the app keeps about AI apps you connect and about the chat on your own API key (Section 5): each conversation and the activity in it, meaning what the AI read and changed, what you and it said to each other, and the changes it asked you to approve; the feedback a connected AI leaves for you to review; and, for seven days, what each of its changes replaced, so that you can undo it. None of this is synced, included in a .t6fv_vault backup, sent to us, or shown to anyone you share a binder with. Removing your account from the device removes it. Keeping these records on your device does not keep your work from the AI: what a connected AI app reads, and what the chat on your own key sends, goes to that AI's provider, as Section 5 describes;
• Local backups the app makes of its own data (on iOS these live in a folder that your device's own iCloud device backup may include, under your Apple account and iCloud settings — that backup belongs to you, not to us).

Device permissions (camera, microphone, photo library, contacts, location, calendar, Bluetooth, local network, speech recognition, notifications) are each requested only for the feature that needs them, with an explanation shown at the time. The app also includes a Permissions overview in Settings describing what each permission is used for. Local network features (teleprompter remotes, on-air signs, Studio Link on your Wi-Fi, lighting control, recording sessions, Virtual Studio screens) communicate between devices on the network you are on — your own, or those of the people you are working with, such as the other devices in a recording session — and do not route through our servers.

Local data is protected by your operating system's app sandboxing and whatever device-level protections you enable (passcode, device encryption). The app's local database is not separately encrypted, and exported .t6fv_vault project archives are encrypted with a format-level key embedded in the app — suitable for keeping project files private in transit, but not a substitute for device security or a guarantee against a determined attacker with the file. Please use your device's security features, and see Section 8 for how Studio Link differs (it uses genuine end-to-end encryption).

3. What We Collect (Only When You Use Cloud Features)

We collect personal information only when you create an account or use a feature that is cloud-connected by design:

Account information. Email address (verified at sign-up), password (held by our authentication provider in hashed form — we never see or store it), unique username, display name, and your interface language (so account emails arrive in your language). Your subscription tier and a subscription event audit trail (event type, entitlement identifiers, timestamps) are recorded against your account.

Purchases. Subscriptions bought inside the mobile app are billed by Apple or Google. Subscriptions started on our website are billed through our billing partner's hosted checkout. In neither case do we receive or store your payment card details. Our subscription platform (RevenueCat) processes purchase and entitlement records linked to your account identifier so your subscription works across your devices. For a web purchase we also hold the billing records we need to answer refund and tax questions about that sale.

Agency plan invoices. The Agency plan is not sold through a store or our web checkout; we invoice the company for it. We email each invoice to the company's Owner as a link to a page that shows it. Where the page offers it, the invoice can be paid there by card through Stripe, into our own Stripe account; otherwise it can be paid by the means the invoice states. Card details are entered on Stripe's page and never reach us. For each card payment, refund or dispute, we hold the identifiers Stripe assigns, the amount and currency, the time, and the payer's name and email address if Stripe collected them at checkout. If someone uses the page to tell us they have paid by other means, we hold what they enter there — a name, an amount and a reference — until we have matched it to the money. Because the invoice is ours, we keep the key to its page with the invoice, so that the Owner can open it again from the app. We keep the invoices and their payment records for as long as tax law requires (Section 9).

Payments you take from your clients. If you connect a Stripe account to the app (available on some plans), your clients' card payments are processed by Stripe on your own Stripe account under Stripe's terms and privacy policy; T6FV is not a party to those payments, holds none of the money, and never receives card numbers — your clients enter them on Stripe's own payment page. So that the app can record a payment on the right invoice, we hold the connection record (your Stripe account identifier, its capability flags, country and settlement currency) and, for each payment, refund or dispute, the identifiers Stripe assigns, the amount and currency, the invoice and link it was for, the time, and the payer's name and email address if Stripe collected them at checkout. A record that a payment event was processed is kept for idempotency (so a repeated notification is never recorded twice) and contains no card data. Your clients' own details entered at Stripe's checkout are Stripe's to protect under their policy, and yours under Section 3A. In a company's workspace this is different: while you hold a seat there, your clients' card payments on your invoices are processed on the company Owner's Stripe account rather than yours (Section 3, "Company workspaces").

Content you publish. Forum posts and replies, Connect listings (which may include a location and a rate you choose to state), your Directory profile, your public Portfolio page (tagline, bio, images, demo video links, rates, social links), a downloadable contact card if you publish one (name, organization, job title, phone number, email — published contact cards are downloadable by anyone who views your public page), Blueprints you upload to the community library (packaged project templates plus preview screenshots, associated with your account), and testimonials.

Messages to you through your Portfolio. If someone contacts you through your public Portfolio page, we hold their message (their name, email, phone number, and message text) so we can show it to you in your inbox.

Portfolio video you upload. If you upload a video to your Portfolio rather than pasting a link to one, we host that file so your public page can play it, and we hold it until you replace or delete it or delete your account. A hosted video is served to whoever views the page.

Push notifications. If you allow notifications, your device is issued a push token by Apple or Google, and we store it against your account so we can send the notification. Tokens are device identifiers for delivery, not tracking identifiers: we do not use them to profile you, and turning notifications off at the operating system level stops them. The content of a notification is generated for something you asked for — an invitation, a moderation notice, an inbox message. We hand each one to Google's Firebase Cloud Messaging, which delivers it and, for an Apple device, passes it to Apple's push notification service (APNs) to deliver; both see the token and the notification's title, which can name the client, person or file it is about. Section 6 lists them.

Team features. If you invite someone to a shared binder, we process the invitee's email address to deliver and gate the invitation, and team activity logs record who did what in the shared binder. The same is true of a company on the Agency plan and of an institution granting Educational access: an administrator adds people by email address, so we hold that address, and the seat or grant it is for, before the person has an account — and we email it to tell them access is waiting. If you are on that list and did not expect to be, the administrator who added you is the person who put it there; you can also ask us at the address in Section 1 to remove it. Where you hold a seat in a company, the company's Owner can see that your account holds it and what kind of seat it is, and the storage allowance may be pooled across the company. Holding a seat does not by itself give the company access to your projects. Joining the company's workspace does, and only after you have agreed to it on a screen that says so, as "Company workspaces" below describes.

Feedback reports. If you choose to submit a feedback report about an AI feature, we receive the feature name, your notes, and basic device diagnostics (device model, OS version, app version, AI model used, token counts), together with your account's name, username and email address, so that we can follow up. The report includes your prompt and the AI's reply only if you tick the box to include them. Reports are visible only to administrators.

Feedback from AI apps you connect. An AI app you connect, or the chat on your own API key, can write feedback about using T6FV. It waits on your device, in the Agent feedback inbox, and nothing is sent until you tap Send. You can edit it or discard it first. If you send it, we receive: a label naming the T6FV tool it is about, or, if none, the name of the connection; the AI's message and any suggestion it made; what the AI says it was doing, only if you tick the box to include it, because that can quote your work; and the category, severity and tool name the AI gave it. We do not receive your device's model or operating system, or any token count. Before an item is stored, and again after you edit it, the app replaces text shaped like an API key, a T6FV connection key or a sign-in header with "[redacted]". It cannot recognize every secret, so read an item before you send it. As with the reports above, we receive it with your account's name, username and email address, and it is visible only to administrators.

Content reports. If you report a post, a profile or an AI answer, we receive the category you chose, any note you added, what you were looking at when you reported it, and which account it belongs to — together with your account name and email address, so a moderator can follow up. The person you reported is not told who reported them. What you saw is included so that a moderator can act on it even if it is edited or deleted afterwards, which means a report can contain another person's words. Reports are visible only to administrators, and we aim to look at every one within 24 hours.

Blocking. If you block someone, we store their account identifier and the time, under your account. It is not shared with them and it is not visible to anyone else.

Bug reports. If you send a bug report from inside the app, we receive what you typed, the area of the app you were in, basic device diagnostics (device model, OS version, app version), whether the app had ended abnormally, and — where the app caught one — the error and its stack trace together with a short trail of the actions immediately before it. That trail is a record of what you did, not of what your projects contain, but it can include names you have given things. Bug reports are sent only when you submit one; nothing is transmitted automatically. Reports are visible only to administrators.

Referrals. If you reach us through a referral link or QR code from someone in our affiliate programme, we record that your account arrived through that referral so the referrer can be credited. The commission ledger itself is kept without your identity: it holds the referral, the amounts and the rates, and not your name, email or account identifier.

Quota accounting. For metered features we keep counters: monthly Blueprint unlock counts, per-Blueprint view counts, Studio Link relay usage meters, the bytes your client links, hosted review video and guests' recordings waiting for you to collect occupy against your plan's storage allowance, the number of client links and pay links you hold, and, for each link, the time its page was last opened — which is what decides whether it has gone unused under Section 9. These are billing/quota records, not behavioural analytics: the last-open time is a timestamp on the link, not a record of who opened it.

T6FV Drive. Some plans include an amount of storage, presented in the app as T6FV Drive. Files you put there — footage, exports, documents, anything you choose — are held for you on Cloudflare R2 under your account, named so that only our servers can sign a link to them (Section 8 says where that stops). We hold them to give them back to you: we do not read them, index their contents, use them, or train models on them. What you put there is entirely your choice, and the app shows what your allowance is and how much is used. Retention is in Section 9.

Editing copies. Footage, photos and field recordings stay on the device that captured them, but you can choose, per production and per device, to share small editing copies of a production's media through your T6FV Drive, so that your other devices can keep editing it. A device with sharing on uploads, to a folder for that production on your T6FV Drive, low-resolution copies of the production's media: video at about 640 pixels and 1 Mbit/s, photos at 2048 pixels as JPEG, and recorded sound compressed as AAC. Your other signed-in devices download them only when they do not have the originals, and only as your "pictures on Wi-Fi" data setting allows. The copies carry no location, camera or other embedded metadata. They count against your T6FV Drive storage. They are deleted when you clear them in Proxies & previews (for a production, a binder, or everything), when the production or binder is deleted, or with your account. A full-quality export always uses the originals; a device that holds only the copies can make a low-resolution draft, which is labeled as one. Transcripts travel with them. When a device that shares a production's editing copies transcribes that production's recordings, the words it heard — each word, when it was said and, where the app told voices apart, which voice said it, with the language — are uploaded to that production's folder on your T6FV Drive, so your other devices can edit by the words without transcribing again. Your other signed-in devices pick them up when they open the production; a transcript is small, so it is downloaded whatever your data setting says. Transcripts are deleted with the production's other editing copies: when you clear them in Proxies & previews, when the production or binder is deleted, or with your account.

Studio Link relay. If you link devices over the internet (rather than your own network), our relay carries only end-to-end encrypted message content between your devices (Section 8) — we cannot read that. To route it, the relay's own records hold the things routing needs: the name of the production, the device and host names you gave, and which pages were asked for. Those are visible to us; the content passing between the devices is not.

Recording links for guests. If you run a recording session, you can invite a guest to record their microphone from a link in a web browser, with no app and no account. Their browser encrypts what they record before it leaves, with a key made from the part of the link after the "#" — which a browser does not send to a server — and our servers keep only a fingerprint of a proof made from the link, never the key, so we cannot open the recording: a copy of our database, our code and our storage together opens no recording we hold. Section 8 says what that rests on and where it stops. The recording is uploaded in pieces while they record, to Cloudflare R2 under the host's account and counted against the host's storage allowance, and the host's device downloads it and opens it there; Section 9 says how long it stays. What the host's app tells the guest's page — such as the host's name, the production's, the guest's name as the host entered it, and when to start and stop — is sealed with a key made from the same link, so we cannot read that either.

What we can see is what running the link needs:

• when a browser last opened the link, and the anonymous sign-in it used — an identifier with the times it was created and last used, and no name or email address, which the browser shares with the other pages we host that sign in the same way, such as a client link's page — which lets only one browser at a time use the link;
• while the page is open, its reports to the host's app, each with its time: whether it is waiting, ready, about to record, recording, uploading, done, out of the host's storage or in trouble, and whether, in the middle of a take, the page was put in the background, its microphone was muted or its audio stopped; which recording it is working on and how much is left to send; the microphone's peak level; how long a round trip to us takes; a label for their browser, such as "Safari on iPhone"; and, once they have agreed, that they agreed;
• for each recording: which of the host's takes it belongs to, and which part of it if the page was reloaded during the take; how many pieces it has and how large each is; its format, and the sample rate measured over it; when it started by the guest's clock, how far that clock was from ours, and how long a round trip to us took at its start and at its end; whether the guest joined after the take had begun, how long it ran, where it was interrupted and whether it ended cleanly; when its upload began and when it was finished; when the guest agreed to be recorded; the browser label; and the name their browser gives the microphone, which can include a person's name if they have named their headset;
• as with any request to our servers, each request's IP address and the browser's full user-agent string, in our server logs, kept for thirty days; Cloudflare sees the IP address of the browser that uploads each piece; and our servers use the IP address as the key of counters that stop a link being misused — each counts requests for an hour, expires two hours after it starts, and our database then deletes it automatically, usually within a day.

Before the guest agrees to be recorded, the page already does part of this: it requests an App Check token (below), signs in anonymously, claims the link, measures its clock against ours, and reports to the host's app every fifteen seconds that it is waiting, with the browser label, the round trip to us and how much it has left to send. The microphone stays off, and nothing is recorded, until they agree; a recording from an earlier visit to the same link that had not finished uploading carries on uploading as soon as the page opens.

The page requests a Firebase App Check token, which our servers do not yet require, and to get one it loads Google's reCAPTCHA to judge whether a script is driving the browser: Google receives the browser's IP address, signals about the browser and device, and its own cookies, and handles them under Google's own Privacy Policy and Terms, not as our service provider; we receive only its verdict. In the guest's browser the page keeps the recording at least until the host's device has collected it (Section 9 says when it can stay longer), which microphone was picked for the link, the anonymous sign-in and App Check's token; reCAPTCHA keeps its own.

Once the host's device has collected a recording it is the host's: a take in their project, like one recorded by a device in their session (Section 2), whose record — which carries the name the host gave the guest — travels in the host's cloud library if their plan has one. The browser label and the microphone's name stay beside the recording on the host's device.

Emails we send. We send transactional email only — verification, password reset and security notices, welcome messages, team and company invitations, notices about a company seat (an invitation declined, a seat ending, client links handed over or closed, an account deletion waiting for, refused or canceled because of a company), our invoices for the Agency plan, notices of changes to our terms and this policy, moderation notices, and service digests relevant to content you published. We do not send third-party marketing.

Website and share pages. Our hosted share pages (for call sheets, scripts, and timers you deliberately share) serve the shared content to whoever holds the link, with referrer information suppressed and caching disabled. Our web pages contain no analytics or advertising scripts.

Guests in a live show. If you run a live show in Virtual Broadcast, you can invite a guest to join it from a link in a web browser, with no app and no account. Their camera and microphone go straight from their browser to the browser running the show, and never pass through us: we do not carry, see, record or store a guest's picture or sound. To find a direct path, both browsers ask public STUN servers run by Google and Cloudflare for their own internet address, so those servers see each browser's IP address, and the two browsers learn each other's addresses as they connect. What the host's app tells the guest's page — the show's name and the guest's name as the host entered it — and the handshake the two browsers exchange through our database to open the call — including the name the guest types and the network addresses each browser offers — are sealed with a key made from the part of the link after the "#", which a browser does not send to a server, so we cannot read them.

The host decides what goes on air. Every guest sees the show back and hears everyone but themselves, so other guests see and hear a guest while they are on air; and the host can record the show on their own device and stream it to destinations they choose. Messages typed into the show's chat go between the two browsers too, never through us. Once a guest's picture or voice is in the host's recording or stream, it is the host's to look after, under Section 3A.

What we can see is what running the link needs: the host's account, when the link was made and when it expires; that a browser claimed the guest's place, with the anonymous sign-in it used — an identifier with the times it was created and last used, and no name or email address, which the browser shares with the other pages we host that sign in the same way — and when; a fingerprint of a proof made from the link, never the link's key; and, while the call is being set up, when the guest's browser sent its offer, whether the guest left and whether the host ended the call. As with any request to our servers, each request's IP address and the browser's full user-agent string are in our server logs, kept for thirty days, and our servers use the IP address as the key of counters that stop a link being misused, which expire two hours after they start and which our database then deletes automatically, usually within a day. Before the guest presses Join, the page has already requested an App Check token, which loads Google's reCAPTCHA as Section 4 describes, signed in anonymously, claimed the guest's place, and asked the STUN servers whether a direct call is possible from this network; the camera and microphone stay off until the guest presses Join. Guests must be at least 18 (Section 11). Section 9 says how long all of this is kept.

Contact sales. If you write to us through the Contact sales form on our page for in-house video teams, what you enter — your name, your work email address, your phone number if you give it, your organization, your role if you give it, and your message — is sent to our team by email at info@t6fv.com, through the Gmail account we send email from (Section 6), with your email address set as the address to reply to. We do not store it in our database. To keep the form from being misused, once you start filling it in the page requests an App Check token, which loads Google's reCAPTCHA as Section 4 describes, and signs in anonymously; and our servers count submissions per email address and per IP address, in counters that expire within two hours and which our database then deletes automatically, usually within a day. As with any request to our servers, the IP address and user-agent string are in our server logs, kept for thirty days. We use what you send only to answer you and follow up on your inquiry.

Talk to a person. If you write to us through the contact form on our homepage, what you enter — your name, your email address, your phone number if you give it, and your message — is sent to our team by email at info@t6fv.com in the same way, with your email address set as the address to reply to. We do not store it in our database. The same protections apply as for Contact sales: once you start filling it in, the page requests an App Check token, which loads Google's reCAPTCHA as Section 4 describes, and signs in anonymously; our servers count submissions per email address and per IP address, in counters that expire within two hours and which our database then deletes automatically, usually within a day; and the IP address and user-agent string are in our server logs, kept for thirty days. We use what you send only to answer you.

Asking about T6FV. Our homepage and our page for in-house video teams each have an assistant that answers questions about what the app does, beside the contact form on that page. What you type there is sent, with the earlier questions and answers from the same visit, to our server on Cloudflare, which picks the relevant parts of our public user manual and has an open-weight AI model that Cloudflare runs for us (Workers AI) write the answer from them. It never receives an account or anything in one. Neither we nor Cloudflare keep what you ask or what it answers, or use either to train a model: our logs record how much computing each answer took and how long, never its words. As with any request, Cloudflare sees the IP address of the browser asking. To keep the assistant from being misused, the page loads Cloudflare Turnstile once you start using it, to tell a person from a script (Section 4); and our server counts each visitor's questions for the day under a code made from their IP address and the date — never the address itself — and deletes every count when the day ends (UTC). The conversation is kept only on the page, and is gone when you leave or reload it. Ask our team copies your questions into the contact form on the same page for you to edit; nothing reaches our team until you send that form.

Time zones and weather for a place you saved. To show a shoot day's sun times in the place's own time zone, the app asks our servers which zone a saved place is in, sending its coordinates rounded to two decimal places (about a kilometer); it asks only after you have accepted this version of the policy, and on Windows only after you have accepted the version of October 10, 2026, the first to say that the app asks there. When someone opens a client link you have published, its page asks our servers for the forecast of any shoot day in the next ten days, sending the day's date and its place rounded to one decimal place (about eleven kilometers), and our servers ask Apple Weather and pass the answer back. Neither question is stored, and the place in it is not logged; the only record either leaves is the per-account and per-connection counter that stops the service being misused. The forecast is never written into the published link: the page fetches it each time it is opened.

Cloud library (plans that include one). While you hold a plan that includes it, the app copies your work to our servers so that every device you sign in on shows the same work. What travels is:

• your planning records — projects, scenes, schedules, contacts, gear, scripts, notes, estimates and paperwork;
• the pictures those records refer to — your letterhead and logo, reference images and stills, the images, looks, models and renders held in the app's Maker libraries, your portfolio, a desk background photo you choose, and a photo you give a hard drive;
• documents you file into a binder — a PDF, a saved email or attachment, a colour look-up table;
• audio you record in the app's music tools, which is filed alongside those libraries;
• the listings of your hard drives' folders, as described below.

What does not travel is what the capture tools record: the library never carries footage or field audio takes, on any plan — only the record of each take, which is a planning record like the rest. A recording made for somebody's recording session does leave your device — to that session's main device, over your local network, as Section 2 describes — but the recording itself never comes to us. The take it becomes there is theirs, and its record travels in their library if they have one.

Records are stored in Google Cloud Firestore under your account. The pictures, documents and audio — and any record too large to be a database document, which is stored as an object rather than a row — are stored in Cloudflare R2 under names only our servers can sign a download link for (Section 8 says where that stops). Both are encrypted in transit and at rest. We use the library to serve your own devices, and the people you invite to a binder, and for nothing else: not for training, not for analytics, not shared with anyone else.

The library also carries the addresses and the keys of the client links you publish, so that any device you sign in on can republish a link, collect what your clients have sent to it, or revoke it — rather than only the one device that created it. On a plan whose cloud library we serve, that means we hold those keys, in your library, under the same access controls as the rest of it. Our Security Overview sets out what that changes and what it does not. Retention when a plan ends is in Section 9.

The library also carries the settings of each mailbox you connect in the mail feature — the email address, the name your mail is sent under, the incoming and outgoing server settings, and, if you add one, the signature you add to your messages (one for your business, and any you set for a particular mailbox), as listed in Section 2 — so that a mailbox you connect on one device appears on your others and asks you only to sign in there. They go to your own devices only: a binder you share never carries them. On a plan whose cloud library we serve, that means we hold your mailbox addresses and their server settings, in your library, under the same access controls as the rest of it; if your devices carry the library through your own iCloud Drive or Google Drive folder instead (Terms §5.8(e)), they travel there and not through us. We never receive the password or sign-in that opens a mailbox, or any of its mail, so holding its settings does not let us read it. Disconnecting a mailbox removes its settings from the library and from every one of your devices.

The library also carries your app preferences, so that a device you sign in on is set up the way you left your others: which tools you keep as favorites and the order they sit in; whether notifications are on, which kinds you get and how many days ahead they warn you; your off-site backup, automatic backup and mobile-data choices; your theme, the app's language, whether helper icons are shown and whether the bottom bar is mirrored; your desk background for light and dark mode, including a photo you choose for it; and the brushes you save in the Graphics Editor — each one's name, its settings (size, hardness, spacing, flow, opacity, how pen pressure drives it, jitter, scatter, steadying and pressure curve) and when it was saved, never anything you draw with it. While you are signed out, the brushes you save stay on that device. Some stay on each device and do not travel: your quiet hours, how many notifications that device keeps in its inbox and for how long, where the windows and icons on that device's desk sit, and which way it syncs. Your preferences go to your own devices only: a binder you share never carries them. On a plan whose cloud library we serve, that means we hold them, in your library, under the same access controls as the rest of it, and a desk background photo is stored with your other pictures; if your devices carry the library through your own iCloud Drive or Google Drive folder instead (Terms §5.8(e)), they travel there and we receive nothing.

The library also carries what you record about the hard drives you add in the Hard Drives tool, so that a drive you plug into another of your computers is recognized there, with the name and notes you gave it, instead of being added a second time. For each drive that is: the name you give it, your notes and tags, and a photo of it if you add one; the folder on the drive where Add production builds a job's folders; which of your productions are linked to which folders on it, each as the folder's path on the drive, which can itself carry a job's name, with the identifiers of the project and the production, not their names; what identifies the volume — its own identifier, its label, its file system and its capacity; and a summary of its last scan — when it ran, how many files and folders the drive held, how many bytes they came to, how much space was free, whether the scan stopped before it finished, and the names of the folders at the top level of the drive, which are often the names of clients or jobs. The files on a drive are never carried, and neither is the search index the app builds of them, the record of files the app has copied there, its transfers, the access your device has given the app to open a drive, or any password you set for the backups it keeps on one: those stay on the device. Your drives go to your own devices only: a binder you share never carries them. On a plan whose cloud library we serve, that means we hold them, in your library, under the same access controls as the rest of it, and a drive's photo is stored with your other pictures; if your devices carry the library through your own iCloud Drive or Google Drive folder instead (Terms §5.8(e)), they travel there and we receive nothing. While you are signed out, what you record about a drive stays on that device. Remove from my account, in a drive's Edit drive sheet, removes the drive's details — and the listing of its folders, below — from the library and from your other devices, leaving each device its own card for the drive; Forget this drive affects only the device you use it on; and neither touches the files on the drive.

The library also carries the listing of each drive's last scan, unless you switch it off for that drive, so that you can search and browse a drive from another of your devices while it is in a drawer. For each drive that is: the name, size and date of every folder and file the scan reached, which can name clients, jobs and people; which folders the scan could not read or recorded only in part; the scan's totals and when it ran; and the name of the device that ran it — the name that device goes by on the sync screen, or, if it has none, what kind of device it is. It never includes where the drive was connected on that device, and the files themselves are never carried. It travels as a few compressed files stored with your pictures, from which each of your other devices builds its own search index; those devices only ever read it. A listing is sent by the device that scanned the drive, for a drive your account has named or linked — on a computer two accounts share, only by the account that ran the scan — on a plan whose cloud library is running; it is replaced by the drive's next scan, at most once an hour, and a listing too large to carry is not sent at all. On a plan whose cloud library we serve, that means we hold it, in your library, under the same access controls as the rest of it; if your devices carry the library through your own iCloud Drive or Google Drive folder instead (Terms §5.8(e)), it travels there and we receive nothing. Turning off Search and browse this drive from my other devices in a drive's Edit drive sheet removes its listing from the library and from your other devices and keeps it on the device that scanned it until you turn it back on; Remove from my account removes it too; Forget this drive does not, because it affects only the device you use it on.

Binders you share (plans that include a cloud library). You can invite named people to a project binder and give each of them an access level. On a company binder, the company's Owner and Admin seats also receive it, at the Manager level, without being invited ("Company workspaces", below). Only the sections that level grants are sent to them — the rest is withheld by our servers and never reaches their device, so a person who may see the schedule but not the money does not receive the money. We hold that copy solely to serve it to the people you named, on the same terms as the rest of your cloud library. When you remove somebody, when they leave, or when you stop sharing a binder, we delete the copy we held for them and the app deletes the copy on their device; what they exported or copied while they had access is outside our reach, and yours. You are the one deciding to share, and about whom: see "You are the one who decides" below.

Company workspaces. A company on the Agency plan can keep its binders in a shared workspace for its seats, which we switch on for each company. This is what it changes.

• Joining is a choice you make, on a screen that says what it means. If a company with a workspace invites an account you already have, the app shows you, before you join, the company, who invited you, the seat you are offered, and how many binders on that device will become the company's, and you have to tick a box to go on. Joining brings in every binder in that account, not only the ones you choose, and the binders you create while you hold the seat join too. Instead of joining, you can decline, or choose "Use another account". That tells the company's Owner, by email and in the app, that you would rather join with a different address, and passes on the address you give, if you give one. If you already hold a seat when a company switches its workspace on, the same screen asks you once, and nothing in your account becomes the company's until you agree. Joining needs a version of the app that shows this screen (build 207 or later), on a device that has accepted this version of this policy.
• What every seat sees. Every seat sees every company binder in a list: its name, its client, its status, its due date, and the names of the person who created it and the person who holds it now. That list does not show a binder's contents, and it never shows a status that reveals money, such as invoiced or paid. To open a binder, a seat needs an invitation. A seat can ask for one from the list. The request, with the asker's name, goes to the person who holds the binder, and the company's Owner and Admin seats can see it too.
• What the Owner and Admin seats see and change. The company's Owner, and any seat the Owner makes an Admin seat once that seat has joined the workspace, can open every company binder at the Manager access level (Section 3, "Binders you share"). That includes the hours people have logged on it (below). The Owner can switch a seat between Admin and User at any time; a seat made a User leaves the binders it was on only because it was an Admin seat. The Owner and Admin seats can also change a company binder's title, status, type and due date. Its client stays with the person who holds the binder, because the client is one of that person's own contacts.
• What we hold for it. For a workspace, our servers hold the list of company binders and the fields above; which seats are Admin seats and which seats have agreed to the workspace; each request for access; the invitations people declined, with any address they asked to use instead; the company's settings, including the inactivity period below and its invoice settings ("Invoicing in a workspace", below); any data fields the company defines for its binders (below); the app build each seat's app last reported; and, for each seat, a note our servers use to tell the seat's devices whether it still holds its seat, with, for each of those devices, the app build it runs, when it first and last reached us, and whether it has confirmed a removal. We hold these on the company's behalf, as Section 3A describes.
• Deleting a company binder. Only the Owner and the Admin seats, once each has agreed to the workspace, can delete a company binder. A User seat cannot, even one it created. A deleted company binder goes to the company's trash: it leaves everybody's binder list, and we copy its records and files to storage the company holds. The Owner or such an Admin seat can restore it for thirty (30) days; if the person who held it has left the company, it is restored to the Owner. Client links on the binder keep working during those thirty days. After that we delete the binder permanently, and the client links its holder published on it close. While the company's plan is suspended or its workspace is switched off, no company binder can be deleted and nothing in the trash is deleted for being thirty days old, though a binder can still be restored; two (2) years after a binder was deleted, it is deleted whatever the company's state (Section 9). Footage, takes and renders never leave the device that made them (Section 2), so the trash cannot hold them, and changes made on a device that was offline when the binder was deleted, and that never synced, are not in it either.
• When a seat ends. Only the company's Owner ends a seat in a workspace, or we do at the Owner's request; it also ends when the company closes (Section 9). You cannot end it by deleting your account while you hold it, except once the company's plan has been suspended for more than thirty days (below; Section 9, and Terms §6.4). The seat does not end at once. First, the app on each of the person's devices is told, and sends us any changes it still holds; we wait up to seventy-two (72) hours for the devices to answer. Before the person is told, we copy every company binder they hold into an archive that belongs to the company. The archive takes the binders and what is filed to them: their productions, schedules, tasks, shots and scenes, their uploaded pictures and documents, the hours logged on them, the values of the company's fields, the invoices and other paperwork filed only to company binders, and the records of the client links the person published on them. It does not take the person's own address book, gear, rate card, Maker libraries, templates or invoice settings, or the decks, drawings, Ideas Boards, social campaigns and gear bookings the app keeps apart from a binder, even one made for a company binder; those stay in the person's account. If the person deletes or moves a company record while the seat is ending, the archive keeps it as it was, marked, so that the Owner can see what changed. Each company binder the person held then passes to the Owner, with everybody else still on it, and is removed from the person's account on our servers. For thirty (30) days after that, anything one of their devices sends back for those binders is added to the archive. The person's access to every company binder ends. Their account itself continues, on whatever plan they hold themselves, with their own things in it: their T6FV Drive, mailbox settings, Portfolio, community posts, Stripe connection and anything else that is not the company's. The person is told in the app and by email.
• Client links on those binders. The client links and pay links the person published on company binders stay up at the same address, showing what they last showed, but they pass to the binder's new holder, and the person who left can no longer change or close them. Card payments on such a pay link go to the company Owner's Stripe account, as every company pay link's do ("Invoicing in a workspace", below), so no client pays the former seat; they are paused only while the company has no Owner whose account can take them, and for the minutes in which a link published again replaces the old one, so that nothing is paid twice. When the holder publishes a link again, from their own copy of the binder, the old one closes. A view link that is not published again closes after ninety (90) days; a pay link does not close for that reason, but it closes before the company's copy it would be published from is deleted (Section 9). If the person who left deletes their account first, their links that have not been published again close with it, and the holder is told.
• Removing it from devices. Everything in a seat's account on a device is treated as the company's. So when a seat ends, the app on each device that held the seat clears the whole account from that device the next time it reaches us — everything the account kept there, including files kept only on that device, and a copy the device kept after the account was signed out there, where that copy shows it held the seat — and signs it out. A device that is open says so, and first sends us the changes it holds. A device that never held the seat, such as a new phone the person signs into afterwards, keeps what it has. The Owner also sets an inactivity period, thirty (30) days unless the Owner changes it, and never less than seven (7) or more than three hundred and sixty-five (365): a device of a seat's account that has not reached our servers for that long clears its own copy of the account by itself, in the same way; the account itself, and its other devices, are not affected. Any contact the device has with our servers, for any account on it, counts, and before it clears the account on screen the app tries to reach us and send the edits it holds. The Owner's own devices are never cleared for inactivity. After a clear, what is still the person's own is in their T6FV account: it comes back when they sign in again on a plan with cloud storage, and on a plan without it is kept for sixty (60) days (Section 9). They sign in to their mailboxes and Google Drive on that device again. If we switch a company's workspace off, nothing more is cleared from a device once that device has next reached us.
• What cannot be removed. Neither we nor the company can reach: anything already exported, printed, shared or copied out of the app, including PDF and spreadsheet exports, .t6fv_vault backups, automatic backups copied off the device, takes copied to a photo library, files handed to another app, mail already sent, and screenshots; files the app keeps for all the accounts on a device together and cannot tell apart by account, such as the pictures in its shared libraries, the Photo Editor's imports and takes not filed to a binder; a device that is never opened again, because the inactivity period is counted by the app on that device; a device running a version of the app older than build 207, which cannot clear itself; and edits that had not reached our servers when a device was cleared, which are lost.
• Handing a company binder to another seat. Whoever holds a company binder can hand it to another seat that has joined the workspace, or to the Owner. It stays the company's. Its contents move from the outgoing holder's account into the company's archive until the new holder brings them into their own library, and they leave the outgoing holder's devices. Its client links stay up under the outgoing holder's account, showing what they last showed, and can no longer be updated; the new holder can close them.
• Bringing a binder back. An archive is the company's. Its Owner sees each archived binder, how much it holds, whether it has been brought in, and which records were changed while the seat was ending, never their contents, and can delete it from the archive. The person who now holds an archived binder — the Owner after a seat ends, or the seat it was handed to — can bring it into their own library, which copies its records and files into their account without replacing anything of theirs that is newer. How long an archive is kept is in Section 9.
• Invoicing in a workspace: who is paid. In a company whose workspace is on, the company's Owner is the one paid. Every card payment a client makes on an invoice a seat issues goes into the Stripe account the Owner has connected, never the seat's, and while you hold a seat you cannot create or connect a Stripe account of your own; one you already had is set aside, unused, and in use again once your seat ends, and you may disconnect it at any time. The tax details, and the business name, address and logo printed on a seat's invoices, are the Owner's too, set for the whole company: we hold them for the company, every seat's app reads them and keeps a copy on its device, and a seat cannot issue or send an invoice until the Owner has saved them. We record when they were first saved, so that a draft made before then is taxed at the company's rate when it is issued, which the app shows first.
• The company's invoice list. Each seat's app reports to our servers the figures of the invoices the seat makes while it holds the seat, and our servers keep them for the company in one list, with the payments they record: each invoice's number and kind, its client's name, its currency, totals and status, its dates, the names of the binders it is for, its card payments, refunds and disputes, what the Owner has done to it, the address of its pay page with the key that opens it, which pay links a checkout for it was opened on, and the payments the Owner recorded on it or the time the Owner voided it. It never holds an invoice's lines or notes, or the client's address or email. Only the Owner can read it — not the Admin seats, not the seat, and not our staff, except through support the Owner asks us for — and the Owner can still read it after the workspace is switched off, so that a card payment can still be refunded.
• What the Owner can do with an invoice. The Owner can void a seat's invoice, record a payment on it, refund a card payment taken into the Owner's account, and ask the seat's app to send it. A void or a recorded payment takes effect at once: our servers make the change in the seat's own cloud library — the invoice, its credit notes and its payment records — and, to make it, read when the invoice was made and last changed, and whether the seat's account is one of ours. The seat is told in the app and by notification, with the invoice's number, and the Owner is told of every card payment in the company, in a notification that may name the person who paid.
• Invoices from before you joined, and when your seat ends. Invoices you made before you joined the workspace stay yours: they are never shown to the Owner, a pay link you published before joining keeps paying your own Stripe account for invoices made before you joined (and the Owner's for any made since), and the PDFs of invoices issued before you joined keep your own letterhead. When your seat ends, the figures of the invoices on the company binders stay in the company's list, now under each binder's new holder; the invoices that stay with you leave it, except while a card payment taken into the Owner's account is on one, so that the Owner can still refund it. None of this applies to an account of ours that holds a seat in a customer's company: nothing of it is mixed into the company's.
• Deleting your account while the company is suspended. Once a company's plan has been suspended for more than thirty (30) days, a seat may delete their account without waiting for the seat to end. Before we delete it, we copy the company binders in it to the company's archive and pass them to the Owner, as when a seat ends, and then delete the account. The device you delete it from sends us the changes it still holds, once, and clears every copy of the account on that device only when we have confirmed that they arrived; if we have not, it keeps the account's data and says so. Your other devices have three minutes to send theirs. The deletion waits, and the account is not deleted, while the company's workspace is switched off — even if it was already off when you asked, if your account holds company binders — or while the company has no Owner who has agreed to the workspace. It waits at most ninety (90) days; after that we delete the account without finishing the copy, keep for the company the copy we had already checked, and are told ourselves. If the company is reinstated first, the deletion is canceled and you are told. If you signed in again while it waited, we ask for your password once more before deleting; if you have not given it within thirty (30) days, the deletion is canceled. A copy kept for a company with no Owner who has agreed to the workspace is the company's, and goes to the first Owner who does. We refuse the deletion, and point you to info@t6fv.com, if the company has no Owner who has agreed to the workspace when you ask, or if the company binders in your account are no longer on our servers, so that your device holds the only copy; a refusal that comes after your device has signed out reaches you in the app and by email. Once the account is deleted, your name and email address are removed from our records of the copy and of the client links it handed over, and from the company's notifications about it; the archive keeps your name and email address, as the record of whose work it is, until it is deleted (Section 9). While a deletion waits, the record that it is waiting is seen only by our administrators.
• What we do with it. We hold a workspace, its archives, its trash and its invoice list on the same terms as the rest of the cloud library, and only to run the workspace for the company. No part of the app and no rule of our database lets our staff read a company's list of binders, a company binder, a request for access, the company's fields, its invoice list, an archive or the trash, and we do not read them. As the Security Overview says of the whole cloud library, we could technically read them as the operator, and that is why we say so here. At the Owner's request, our staff can change a company's seats, their roles and its settings, end a seat, bring an archived binder into the library of the person who holds it, delete it from the archive, close the company, and look into its invoice list for the Owner. Our servers do each of these without showing us any binder's contents.

Time you log on tasks. A binder's tasks can carry a record of the time people spent on them. Each person has one record per binder. It holds the task, the date and the start and stop times of each stretch of work, how the stretch was recorded (a timer someone started, a calendar booking they chose to include, or times typed in), any note, a total set by hand, and which bookings the person included or set aside. The app records time only when somebody does one of those things. It does not watch what you do: no activity, keystrokes, screens, location or idle time are recorded, and a timer runs only between the moments someone starts and stops it. Anyone who can change a binder's brief (its owner, a Manager or Admin seat, or a Producer) can correct another person's times. Everyone else can change only their own.

On a plan with a cloud library, these records go to your own devices. On a shared binder, your record goes to you and to the people who can change the binder's brief (its owner, Managers and Producers, and on a company binder its Owner and Admin seats), who can see who logged how much time, on which task, and when, across the whole binder even where their access is limited to some of its productions. The other people assigned to a task you logged time on see only how much time each person has on that task, whether their timer is running, and which of its bookings each person included, not the times of day or any note. Anyone who can edit a binder's tasks can assign themselves to one, and that change shows on the task. Everyone else on the binder sees none of your hours. This is enforced by our servers' access rules, not only by what the app chooses to show. They are never sent to a Studio Link Viewer. A device that has not accepted this version of the policy keeps them on that device and sends none until it does. They are included in a whole-library .t6fv_vault backup and in the app's automatic backups, but not in a single binder's export, a duplicate, or a Blueprint. The app can offer logged time to the pricing calculator on your own device, as a suggestion you can take or leave.

Fields a studio or company defines. An account's owner can add their own fields to every binder: a date, a number, a choice from a list, a formula. The definitions are kept in the owner's library. On a company workspace, the company's Owner defines them for the whole company, and our servers hold those definitions so that every seat's app can show them, in place of any the seat defined for themselves. A field's value on a binder travels with the binder to the people who can see its brief. What a field is for, and whether it records anything about a person, is the decision of whoever defines it, under Section 3A.

3A. Information About Other People That You Enter

Most of what you keep in the app is about somebody else — crew, cast, talent, clients and their contacts. Names, phone numbers and emails (including anything you import from your device's address book), rates, call times, images and footage of identifiable people, and free-text notes. Some fields invite genuinely sensitive information: a crew member's dietary requirement or allergy, a performer's measurements, an accessibility need. In some places, notably productions involving children, it will be information about a minor.

Two things follow from that, and they matter.

You are the one who decides. For the information you enter about other people, you decide what to collect and why, and you are the one responsible to them for it — under the GDPR you would be the controller and, for the copy the cloud library holds, we would be your processor. In a company workspace, the company is the one deciding, through its Owner: about the binders its seats keep, about the data fields it defines, and about what it holds on its own seats, including the hours they log. It is the company that is responsible to those people, including for any notice its employment law requires it to give its staff, and we act for the company. Inviting somebody to a binder is a disclosure you are making, not one we are making: choose who to invite, and what to grant them, with that in mind. Letting an AI read it is the same. If you connect an AI app, or chat on your own API key, and let it read binders, contacts, documents or footage that are about other people, that is a disclosure you are making to the company behind that AI, not one we are making. It is for you to have a lawful basis for it, to give any notice your law requires, and to honor any confidentiality you owe. Contact details, money, documents and tables are off for every connection until you turn them on. While contact details are off, the app strips phone numbers, email addresses, dietary, allergy and measurement notes and information about minors from what the AI reads. Turn them on only where the job needs it. That means having a lawful basis, giving whatever notice or getting whatever consent your law requires, keeping it accurate, answering the requests those people can make of you, and not collecting more than the job needs. Recording somebody is the same. If you invite a guest to record from a recording link, telling them that they will be recorded, by whom and for what, and having their agreement — which the law of some places requires of everyone on a recording — is yours to do; the page asks the guest to agree before it turns on their microphone, and notes when they did, but that does not do it for you. Dietary, medical, accessibility and similar notes are treated as sensitive or special-category information in many places, and information about children more strictly again. Record it only where you actually need it. Our Terms of Use §7.9 says the same thing as an obligation.

We do not look at it. Where a plan includes the cloud library, we hold this information solely to serve it back to your own devices and to the people you have invited to your binders, and on a company binder to the company's Owner and Admin seats. It is encrypted in transit and at rest, and reachable by no account other than those. We do not read it, mine it, share it, sell it, or train models on it. If you need a written data processing agreement, ask us at the address in Section 1.

What our sharing tools do with it. Share links, export links, call sheets and published pages disclose whatever you put in them to whoever holds the link. The app is deliberately careful with the most sensitive of it: you choose which sections a link carries when you create it, and a section you leave out is absent from the published file rather than hidden inside it; and where a link goes to someone working on the job rather than to your client, the catering order detail is withheld regardless of what you chose, because a crew member reading a binder is not owed the room's dietary requirements. Beyond that, which link goes to whom is your decision, and the safest habit is to send the least the recipient needs.

4. What We Do NOT Do

• No analytics or telemetry SDKs. The app contains no product analytics, usage tracking, or behavioural profiling.
• No third-party crash or analytics SDKs. Nothing reports a crash to anyone automatically. The app can notice that it closed abnormally and offer you the chance to send a bug report, and that report goes only when you send it (Section 3).
• No advertising, ad networks, or attribution SDKs.
• No tracking identifiers. We do not access the advertising identifier (IDFA/AAID), do not fingerprint devices ourselves, and do not track you across apps or websites. Our iOS privacy manifest declares tracking as "false" with no tracking domains. Some ordinary browser storage is worth naming so this claim is not read as wider than it is; none of it is an advertising identifier. If you arrive through an affiliate link, that referral code is kept in your browser so the person who referred you is still credited if you sign up on a later visit — clearing your site data removes it, and it is never linked to an advertising profile. A client-link page remembers the name you typed on it, so you are not asked again on your next visit; that lives in your own browser, and we do not receive it. A recording link's page keeps the recording at least until the host has it (Section 9 says when it can stay longer), which microphone was picked, and the anonymous sign-in that holds the link, which it sends us with each request and which the other pages we host that sign in the same way share (Section 3); a live show's guest page and the Contact sales form keep the same anonymous sign-in, and nothing else of their own. And the pages we host that use Firebase App Check — a recording link's page among them — load Google's reCAPTCHA, which reads signals about the browser and device, and keeps its own cookies, to tell a person from a script; that is Google's processing, under Google's own policy, and we receive only its verdict. The page for in-house video teams also loads Cloudflare Turnstile, for the same purpose, once you start asking its assistant a question (Section 3); Cloudflare runs it for us, and we receive only its verdict.
• No record of where you are. Your device's own position never reaches us. The time-zone and weather questions described in Section 2 carry a place you saved, rounded, not where you are, and they are answered and forgotten rather than stored.
• No watching how you work. The app does not record activity, keystrokes, screens or idle time. Time on a task is recorded only when someone starts a timer, includes a booking, or types it in (Section 3, "Time you log on tasks").
• No sale or sharing of personal information for advertising or any other consideration.
• No AI training on your content. Neither your local data nor content you publish is used by us to train AI or machine learning models, and our retention of archived content excludes AI training use by commitment in our Terms of Use.
• No AI company of ours receives your content. We do not send your content to an AI provider. Where an AI company does receive it, you sent it: by connecting its app, by entering its API key, or by pasting a prompt into its website. You sent it under your own agreement with that company, whose terms decide whether it keeps your content or trains on it (Section 5).
• No collection from children. The Services require users to be 18 or older. See Section 11 for information about children, which is a different question.
• No reading of your mail. If you connect a mailbox, its messages are cached on your device. We do not receive your messages or their attachments and hold no copy of them, and we never receive the password or sign-in that opens the mailbox — so we cannot read your mail. Three things about it can reach us, and Section 2 describes each: on a plan whose cloud library we serve, the mailbox's settings — its address and server details, so that your other devices can list it; a message or attachment you save into a binder; and the short filing record — sender, subject, date, opening line — that a message you file against a job leaves on that job's correspondence list.

5. AI Features and Your Content

The app's AI features are designed so that you control where your content goes:

On-device AI. Optional AI models run entirely on your device. Prompts, project context, and outputs stay local. A model file reaches you one way and one way only: the app downloads it from our own content delivery network at models.t6fv.io, which runs on Cloudflare R2. That download reveals your IP address to us and to Cloudflare, as any download does, and carries none of your content. The app does not fetch model files from anywhere else and does not send you to any other site to get one. The repository each model was published in is named on its licence card, as text, so you can check where the bytes came from.

External AI hand-off. For some tasks the app prepares a prompt (which may include project details you've selected — scene lists, script text, gear lists, and similar) and copies it to your clipboard or opens the website of an AI service you have an account with (ChatGPT, Claude, Gemini, Copilot, Perplexity, Grok, DeepSeek, or Le Chat). You decide whether to submit it. What you submit is processed by that provider under its privacy policy, not ours — we are not a party to that exchange and receive nothing from it. Be careful not to paste content you owe confidentiality for.

AI apps you connect (Mac and Windows). You can let an AI app installed on your computer, such as Claude Desktop, Claude Code, Cursor, Visual Studio Code, Codex in the ChatGPT app, Antigravity, Gemini CLI, or another app that supports the Model Context Protocol, read and, if you allow, change your work in T6FV: project binders, scripts, documents, workbooks, presentations, drawings, photo catalogs, video cuts with their footage details, transcripts and still frames, and motion graphics projects. To make that possible, the app listens for that AI app on your own computer only. It cannot be reached from your network or the internet. Each connection has its own key, and the app keeps only a fingerprint of it, on your device, for the account that made it. For each connection you choose whether it may only read, make changes as it goes, or ask you before each change; which tools it may use; and which binders it may reach. By default it may reach the binders you own. It can never reach binders other people have shared with you. On a company workspace it can reach company binders only as far as your own seat can, and its changes there show as yours, with the connection's name, in the company's activity. Four areas are off until you turn them on for a connection: money (rates, budgets, quotes and invoices), contact details, documents (agreements and other paperwork) and tables (workbooks). Deleting, sending, sharing, replacing a file and any change to money always ask you first. A connected AI can never sign or approve anything, change your account, your settings or what a connection may do, or touch invoices or signed agreements. Every change it makes shows in the app as it happens, and you can undo it for seven days. If a change would alter what a client sees on a client link you have published, that page is not updated until you tap Release.

We do not send any of this to an AI company. The AI app does. What it reads goes to the company that makes it, or to the AI service you have set it up to use, under your agreement with that company and its privacy policy, not ours. Depending on your plan and settings with that company, it may keep what it receives, or use it to improve its models. We cannot see or control what a connected AI app, or the company behind it, does with what it reads. Text that the AI reads, including text written by your clients or by other people, can try to mislead it, so check what it changed, and remove a connection you no longer use.

Chat on your own API key (Mac and Windows). You can paste an API key of your own from Anthropic, OpenAI or Google into the app. It is kept in your computer's own secure storage (the keychain), for your account only, and is sent only to the company that issued it, with each request. When you chat, the app sends, from your computer directly to that company: your messages; the app's own instructions and the descriptions of its tools; and what those tools read from your work for the answer, under the same choices and the same four switches as a connected app. We are not involved, and nothing passes through our servers. That company bills you under your agreement with it. The app keeps only an estimate of what you have spent each month, on your device, and stops at a monthly limit if you set one. When you chat through OpenAI, the app asks OpenAI not to store the conversation for later retrieval. Google's terms for a key on Gemini's free tier let Google use what is sent to improve its products, so the app asks you whether your key is on a paid Google Cloud project, and warns you if it is not. Each company's own terms say how long it keeps what it receives.

"Connected AI" on the app's AI buttons. Once you have added your own key, the app's existing AI buttons offer Connected AI alongside your own AI and the on-device one. Choosing it sends that button's prompt, which can include the project details the button works from, to the same company on the same key, and shows the answer as text. It uses no tools. The four switches above decide what tools may read, so they do not change what a button's prompt contains: it is the same prompt the button would otherwise copy for you to paste.

Voice dictation and voice-follow. These use your device operating system's speech recognition. Depending on the device and OS settings, audio may be sent to Apple's or Google's speech recognition servers and handled under their policies. If you do not want dictation audio processed off-device, do not use the dictation features (or configure on-device dictation at the OS level where your platform offers it).

On-device machine learning. Text recognition (reading camera-body labels), face/pose detection (photo editing aids), and translation run on-device via Apple's and Google's on-device ML frameworks. Photos processed by these features are not uploaded. The app's interface translations come from catalogs shipped inside the app itself, so in ordinary use nothing is fetched to translate it. On Android and iOS, where a phrase has no shipped translation the app can fall back to Google's on-device translator, and that fall-back downloads a language model from Google the first time it is used for a language — the download tells Google your device is asking for it, as any download does, and carries none of your content; the translation itself then runs on your device.

Speech recognition on your device. The Social Clips tool can transcribe a video you already hold using a Whisper speech model that runs entirely on your device. The audio stays there, and so does the transcript, unless it is a transcript of a production's recordings that travels as Section 3 describes under "Editing copies". This is separate from dictation, which uses your operating system's own service and is described above.

Optional AI web search. On desktop, larger on-device models can be allowed to search the web before answering. Off by default. When enabled, search queries composed from your prompt are sent to a third-party search service (DuckDuckGo), and result pages may be fetched. Leave it off if no part of your prompt should leave the device.

The assistant on our website. Separate from the app, our homepage and our page for in-house video teams have an assistant that answers questions about the app from our public user manual, using an open-weight model that Cloudflare runs for us. It receives only what a visitor types into it, never your account or your content, and nothing it is asked is kept or used for training; Section 3 says what happens to a question.

We can switch AI connections off. We can turn these features off for everyone, from our servers. The app checks a setting when it starts and from time to time, and sends nothing about you or your connections when it does.

6. Service Providers and Other Recipients

We use a small number of service providers to operate the cloud features, each processing personal information on our behalf under their own security commitments:

Google's reCAPTCHA, which the pages we host that request Firebase App Check tokens load, is not in this table: Google runs it under its own Privacy Policy and Terms rather than as our service provider, as Sections 3 and 4 describe. Nor are the public STUN servers that a live show's browsers ask for their own internet address (Section 3), run by Google (stun.l.google.com) and Cloudflare (stun.cloudflare.com): a browser contacts them directly, they see its IP address, and they run under their operators' own terms.

AI apps you connect, and the companies whose API key you enter in the app (Anthropic, OpenAI and Google), are not in this table either, because they are not our service providers. We do not engage them, pay them or send them anything. They receive what you let them read, from your own computer, under your agreement with them and their privacy policies (Section 5). The same is true of where they process it.

Beyond service providers, we disclose personal information only: (a) to other users and the public, at your direction — content you publish is public by design (Section 3); (b) for legal reasons — where required by law, regulation, subpoena, or court order, or to protect the rights, safety, or property of users, the public, or T6FV; (c) in a business transaction — if T6FV is involved in a merger, acquisition, financing, or sale of assets, personal information may be transferred as part of that transaction, subject to this policy's commitments; and (d) with your consent in any other case.

We do not disclose personal information to data brokers, advertisers, or AI training aggregators.

7. International Transfers

We are a Canadian company. Our database, accounts, server logic and transactional email run on Google Cloud in the United States (region us-central1), and your account information and published content are stored and processed there, where they are subject to lawful access under U.S. law.

Files are different, and this is the part to read if you are in the EEA, the UK or Quebec. The files described in Section 3 — what you put on T6FV Drive, the media and review video on your client links, the pictures, documents and audio your cloud library refers to, and a guest's recording on its way to the host — are stored by Cloudflare (R2) on its global network rather than in a single named region, and Cloudflare may hold or serve them from outside Canada and outside the United States. Cloudflare is a processor acting on our instructions, and the transfer safeguards below cover it as they cover the others. We do not currently offer a choice of storage region; our Security Overview says so too.

• Canada (PIPEDA): we remain accountable for personal information transferred to service providers for processing, and use contractual and technical safeguards to require comparable protection.
• EEA / UK (GDPR / UK GDPR): where we process personal data of individuals in the EEA or UK, transfers to our processors outside those areas rely on the European Commission's Standard Contractual Clauses / the UK Addendum (our processors — Google, Cloudflare, RevenueCat, Stripe — incorporate these in their data processing terms), together with supplementary technical measures.
• Quebec (Law 25): personal information communicated outside Quebec is assessed for adequate protection under the applicable factors before transfer.

8. Security

Proportionate to what we actually hold:

• All communication between the app and our servers uses TLS encryption in transit; data at rest with our cloud providers is encrypted by those providers.
• Access to your private account record is restricted server-side to you: our database security rules make account documents owner-only, and only an allowlisted subset of profile fields you choose to publish is ever publicly readable. Your email address, role, and subscription details are never in the public projection.
• Studio Link is end-to-end encrypted. When your devices link over the internet, they agree on a session key using ephemeral X25519 key exchange, and content is encrypted with AES-GCM. The key never leaves your two devices, and our relay stores only ciphertext we cannot read.
• A recording link's recordings are encrypted in the guest's browser. Each piece is sealed with AES-GCM under a key made from the part of the link after the "#", which a browser does not send to any server. Our servers keep only a fingerprint of a proof made from the link — enough to check that a caller holds the link, never enough to open anything — so a copy of our database, our code and our storage together opens no recording we hold. That has two limits. The link is itself the key: anyone who holds it holds the key to its recordings, and can record into it until it expires or is turned off. And the guest's browser runs a page served from our website each time the link is opened, not an app installed on their device, so recordings made later depend on that page, and the Google reCAPTCHA script it loads, not being changed to send the link anywhere. The app keeps its copy of the link on the host's device that sent the invitation and does not copy it to the host's other devices or cloud library, although an operating-system backup restored to a new device carries it.
• A live show's guest call is direct. A guest's camera and microphone go between the two browsers over an encrypted WebRTC connection, with no relay of ours in between. The handshake that opens it, and the names the host and the guest gave, are sealed with AES-GCM under a key made from the part of the link after the "#", which we never receive. The link is itself the key: anyone who holds it can take the guest's place until the host ends it or it expires, so share it only with the guest.
• A Virtual Studio show's media crosses your Wi-Fi without encryption, because a browser on a local network cannot decrypt it. It is sent only to devices that joined with the show's code, each only what it shows. Use a Wi-Fi network you trust, or a hotspot of your own.
• AI connections stay on your computer, and are not encrypted there. The app listens for a connected AI app only on your computer's own loopback address, which nothing on your network can reach, and refuses requests from web pages. Every request must carry that connection's key. Traffic between the two apps does not leave your computer and is not encrypted, so other software running as you on the same computer could watch it, just as it could read your files. A request from the chat on your own key goes to the AI company over TLS.
• Community Blueprint files are stored in closed storage and served through short-lived (15-minute) signed URLs.
• Server endpoints are protected by rate limiting, per address and per IP; our database has deletion protection, point-in-time recovery, and scheduled backups. Device attestation (Play Integrity / Apple DeviceCheck) is built into the app and is being rolled out — it is not yet enforced on our endpoints, so we do not count it as a protection here.
• We honestly describe the limits: local app storage relies on OS sandboxing and device encryption (Section 2), and vault exports use format-level encryption with an app-embedded key rather than a per-user secret — which obscures the file but does not keep it secret from us. Media attached to client export links is protected by unguessable URLs rather than encryption. A recording sent to a recording session's main device is checked on arrival against a fingerprint of the file, and only a device holding the session's code can send one, but it crosses the local network without encryption of its own — it is as private as the Wi-Fi it travels on, so record on a network you trust. A client link's content is encrypted before it is uploaded, and since September 2026 the key that opens it travels in your cloud library so that any of your devices can revoke the link — so on a plan whose library we serve, we hold that key as well as the encrypted page. Files we keep in Cloudflare R2 are named so that only our servers sign download links for them, but the public address we serve published media from reaches the same storage, so until a rule limiting that address to published files is confirmed in place, a file there — on T6FV Drive or in a cloud library — can be fetched by anyone who knows its full name, which includes the account's identifier, and a guest's encrypted recording by anyone who knows its full name, which is long and random and names no account. Our full security posture, including what we do not have yet, is set out in our Security Overview.

No system is perfectly secure. If a breach of security safeguards involving your personal information creates a real risk of significant harm, we will notify you and the appropriate authorities (including the Office of the Privacy Commissioner of Canada and, where applicable, provincial and foreign authorities) as required by law.

9. Retention and Deletion

You control local data. It lives on your device; deleting the app (or using its own delete functions) removes it. We hold no copy. A recording you sent to somebody's recording session is also in their project, and deleting yours does not remove theirs.

AI connections keep everything on the device, and we hold none of it. A conversation with a connected AI app, or in the chat on your own key, stays until you delete it or, unless you pin it, until ninety (90) days after its last activity. What each change replaced, kept so that you can undo it, stays for seven (7) days. An item of Agent feedback stays until you send or discard it. A connection's key fingerprint and settings stay until you remove the connection; a removed connection, or one that was never used within seven days of being set up, stays listed for seven (7) days more. Your own API keys stay until you remove them, along with the monthly spend estimate. Removing your account from the device removes all of it. What a connected AI app or an AI company has already received is kept under its own terms, and deleting it here does not delete it there.

Account data is retained while your account is active. When you delete your account (in-app: Profile → Delete Account, with password confirmation):

• Your account record, portfolio content (projects, services, specializations, testimonials), and inbound portfolio messages are deleted;
• Your uploaded portfolio and profile images are deleted from storage;
• Your username reservation is released;
• Your Forum, Connect, and community posts are anonymized — the content may remain, but your name, username, avatar, and profile links are removed from it;
• Your email address is removed from Blueprints you had published;
• Your authentication record is deleted last, ending your ability to sign in.

Cloud library (for plans that include one) is retained while the plan is active. The copy on our servers is the records and the pictures, documents and audio stored with them, and the client-link keys, mailbox settings, app preferences, hard drive details and hard drive listings the library carries; wherever this section says the library is deleted, all of that is deleted with it. A file no record refers to any more — because you removed the picture, or deleted the record that pointed at it — is removed by a clean-up that runs weekly. That includes a drive's listing: the one a new scan replaces, and the one you switch off or remove with the drive from your account, is removed the same way. The copy held for somebody you shared a binder with is deleted as soon as you remove them, they leave, or you stop sharing that binder. When paid access ends, syncing stops and the copy on our servers is held unchanged for 60 days so that resubscribing restores it; we email you when the hold starts and again before it ends, and at the end of that period the copy is permanently deleted. Deleting your account deletes it immediately, without the hold. While your account holds a seat in a company's workspace that you have joined, it cannot be deleted until the seat has ended, except after a long suspension as below, so that the company binders in it reach the company first ("Company workspaces", below; Terms §6.4). Neither deletion touches the copies on your own devices, which remain yours.

Company workspaces. A deleted company binder stays in the company's trash for thirty (30) days, so that the Owner or an Admin seat can restore it, and is then deleted permanently, with its records and files. While the company's plan is suspended, its workspace is switched off or the company is closed, nothing in the trash is deleted for being thirty days old: a binder that has been there longer is deleted once the workspace runs again, and in any case two (2) years after it was deleted, whatever the company's state. A binder still being moved into the trash at that point goes back to the person who held it, in a closed company as an ordinary binder of theirs. A former seat's archive is kept for the company until its Owner deletes it, and for no longer than two (2) years after the seat ended. From fifteen (15) days before the two years end, the client links still waiting to be published again from it close and the binders' holder is told, and the archive is deleted, with the name, email address and library notes it kept about the person, before the two years end: our clean-up runs daily, and deletes it on its first run from the day before. An archive made when a company binder is handed from one seat to another is kept until the seat it was handed to brings it into their library, and we remind them once a year; once it has been brought in whole it is deleted, and if anything of it was left out, it is kept for no longer than two years after the handoff. A part-made copy left by a removal that stopped before it finished is deleted once the removal has stopped, if nothing was taken out of the person's library; if anything was, it is kept like an archive. When an archive goes, so do our other records of that seat's ending: the record of the removal, the records of its client links, the record of what came back from the person's devices, the names in the company's notifications about it, the record our servers kept of the seat's devices, and, for a closed company, the address of an Owner it was waiting for and the names on its roster. If a letter about it could not be delivered, we keep only which holder and which archive it was, so that we can follow it up. Two things can keep an archive longer, and we resolve each by hand: an archive whose end date our records do not hold, and one with a client link that will not close. When a company is closed, every seat is ended as Section 3 describes, each company binder becomes an ordinary binder of the Owner, and the company's trash and archives are kept for the Owner to bring in, under the same limits. The company's invoice list is kept while the company exists and is deleted when the company is closed, with our records of what the Owner did to its invoices. The invoices themselves stay in the libraries of the people who hold them, and a card payment taken into the Owner's Stripe account can still be refunded there. While a company's plan is suspended, a seat whose own plan has no cloud library has their cloud copy kept but not served for up to thirty (30) days, and then held for the sixty (60) days above, which do not delete it while a copy for the company is still to be made. Once the suspension has lasted more than thirty days, the seat may delete their account, and the company binders in it are copied to the company first (Section 3, "Company workspaces"). Time logged on a binder stays with the binder after the person who logged it leaves it, under the name they had then, and is deleted with the binder.

T6FV Drive keeps what you put on it until you remove it. A file on the drive is not deleted for being old, unopened, or unreferenced, and nothing sweeps it. One thing you do removes a file later rather than at once. When you move a file you added to a binder to the app's Trash, its T6FV Drive copy is kept while the file is in the Trash, so you can put it back, and it is deleted when you empty the Trash, when you delete that file from the Trash, or thirty (30) days after you moved it there, whichever comes first. Putting the file back before then keeps its copy. Copies on your own hard drives are never touched. Editing copies are the exception, because the app made them rather than you: they are deleted when you clear them in Proxies & previews, when their production or binder is deleted, or with your account. If your paid access lapses the drive is not frozen or emptied: you can still list and download everything on it, and still delete files, for as long as your account exists — what stops is adding new files. Deleting your account deletes every file on the drive immediately, with no hold, so take copies of anything you want to keep before you delete. This is deliberately different from the cloud library above, which is held for 60 days and then removed.

Client links (for plans that include them) publish an encrypted copy of the content you choose to a page your client can open, and hold what your clients submit on that page (notes, task check-offs, signed approvals, and payment reports — the name, amount and reference a client enters when they tell you they have paid) until your app collects it. That content is retained while the link exists — and a link is not kept forever: a link that no client has opened for twelve (12) months is deleted, together with its published copy and any uncollected client submissions, and we email you at least thirty (30) days before that happens so you can open or republish it if you still need it. Republishing a link, or anyone opening its page, restarts the twelve months. A pay link (a client link that carries an invoice) is deleted on the same basis, and also as soon as you void or delete the invoice it was issued for. When your paid access ends, the pages close to clients immediately and everything clients sent is held for 60 days so you can save it to your devices and so resubscribing restores the links; we email you when the hold starts, and at the end of it the links and any uncollected client submissions are permanently deleted. Deleting a link yourself deletes its published copy and any uncollected client submissions at once — the app first saves what it can to your device and warns you about anything it cannot. Deleting your account deletes all of your client links, their published pages, and any uncollected client submissions immediately, without the hold. Copies already saved to your devices remain yours.

Recording links hold a guest's recording in our storage only until the host's device collects it: once it has downloaded the recording and filed it as a take, it deletes our copy. A recording the host's device never collects, or that never finished uploading, becomes due for deletion fourteen days after the expiry its link had when the recording was made, and our weekly clean-up deletes it the first time it runs after that — normally within twenty-one days of that expiry. What we keep about each recording — the details Section 3 lists — goes with it. A link stops taking new recordings when it expires — which the host's app can set, each time it sets it, no more than eight days ahead — or when the host turns it off or ends the session. A recording already under way when the session ends has up to a day to finish uploading, but never past the link's expiry; and a piece the page had already been given an upload address for can still arrive up to an hour after any of these. The link's own records, including the page's reports to the host's app and which anonymous sign-in held the link, are deleted by the same weekly clean-up once the session's links have been expired for a day. The anonymous sign-in itself is deleted automatically by our authentication provider about thirty days after it was created. Deleting the host's account deletes the rest at once, except that a piece the guest's page had already been given an upload address for can still arrive within the following hour; our weekly clean-up deletes it the first time it runs after that. The recording the host collected is theirs, in their project, and deleting the link does not remove it.

The guest's browser keeps its own copy of what they recorded, so that a dropped connection loses nothing and they can save a copy, and the page asks the browser not to clear it on its own. The page deletes a recording from that copy only while it is open and has been told that the host's device collected it. A recording the link refused is not deleted, and once the link's records have been cleared the page is never told; so a copy can stay in that browser until the guest clears its data for the site.

Live show links work for about a day: a link expires a day after the host invites the guest, or sooner if the host ends the guest's place, and the host's app can never set it more than two days ahead. Our daily clean-up deletes a show's link records — the sealed names, the handshake and which anonymous sign-in claimed each place — the first time it runs a day after the show's links have expired, normally within two days of that expiry; deleting the host's account deletes them at once. The anonymous sign-in itself is deleted automatically by our authentication provider about thirty days after it was created. We never hold the guest's picture or sound, so there is nothing of it to delete; what the host recorded is theirs.

Messages from our website's contact forms (Contact sales and the homepage's) are not stored on our servers. The email that carries one stays in our inbox for as long as we need it to answer you and follow up; ask the Privacy Officer (Section 1) and we will delete it.

Backup copies held for disaster recovery cycle out on a fixed schedule (our database keeps point-in-time recovery for 7 days plus scheduled backups). Records we are legally required to keep (for example, subscription transaction records, and our invoices for the Agency plan and their payments, for tax purposes) are retained for the legally required period and then deleted. Unverified accounts are subject to scheduled cleanup. Feedback reports and bug reports you sent stay with us after you delete your account, with your name, username and email address removed from them. Deleting your account does not cancel an app-store subscription — cancel it in your store settings.

10. Your Rights

Everyone: you can access and correct most of your information directly in the app (profile, portfolio, published content), delete individual posts and content, and delete your account entirely in-app. For anything you cannot do in-app, contact the Privacy Officer (Section 1). We respond to access and correction requests within the time required by applicable law (30 days under PIPEDA, extendable as the law permits), and we do not discriminate against you for exercising any right.

Canada (PIPEDA and provincial laws): you may request access to the personal information we hold about you, request corrections, withdraw consent (subject to legal or contractual restrictions — withdrawing consent for account data means closing the account), and challenge our compliance. If you are unsatisfied with our response, you may complain to the Office of the Privacy Commissioner of Canada (priv.gc.ca).

Quebec (Law 25): you additionally have rights to data portability of computerized personal information you provided, to request de-indexing or cessation of dissemination in certain circumstances, and to complain to the Commission d'accès à l'information du Québec. We do not make decisions about you based exclusively on automated processing.

EEA / UK (GDPR / UK GDPR): where GDPR applies to our processing, we process personal data on these legal bases: performance of a contract (account, subscriptions, cloud features you use); legitimate interests (service security, abuse prevention, defending legal claims — balanced against your rights); consent (optional features that send data off-device where we ask first, such as translation pack downloads, including prompts in feedback reports, and including what a connected AI says it was doing in feedback you send from AI connections); and legal obligation (tax and accounting records). You have the rights of access, rectification, erasure, restriction, portability, and objection, and the right to withdraw consent at any time without affecting prior processing. You may lodge a complaint with your local supervisory authority or the UK Information Commissioner's Office. We have not appointed an EEA/UK representative; we are a Canadian company and offer the Services globally through the app stores.

United States (state privacy laws, including California CCPA/CPRA): we do not sell personal information, do not share it for cross-context behavioural advertising, and do not use or disclose sensitive personal information for purposes requiring a right to limit. You have the rights to know, access, correct, and delete, exercisable in-app or through the Privacy Officer, and the right not to be discriminated against for exercising them. Because we do not sell or share personal information, no "Do Not Sell or Share" mechanism is required, and we treat universal opt-out signals as satisfied by default.

Verification: for requests made outside the app, we verify identity against the account email before acting, and we may decline requests that are manifestly unfounded or excessive, as the law allows.

11. Children

The Services are for adults. You must be at least 18 to use them (our Terms of Use, and in-app age confirmations, require this). We do not knowingly collect personal information from anyone under 18; if we learn we have, we will delete it. If you believe a minor has provided us personal information, contact the Privacy Officer.

That is a different question from information about a minor. Productions involve children, and the app will hold what you put in it — a young performer's name and call time, a guardian's contact details, footage of a child, a signed minor release. We do not solicit any of it and we do not use it. Where you record it, you are responsible for it under Section 3A, and the law protecting children's information is stricter than the rest; a guardian's consent is usually the least of what is required.

12. Changes to This Policy

We may update this policy as the Services evolve. Material changes will be announced by email and/or prominent in-app notice at least thirty (30) days before they take effect where feasible; the "Last Updated" date always reflects the current version. Continued use of the cloud features after the effective date constitutes acceptance of the updated policy, to the extent permitted by law. Prior versions are available on request.

13. Contact and Complaints

Privacy Officer, THE 6-FIGURE VIDEOGRAPHER LTD., Mississauga, Ontario, Canada — info@t6fv.com.

If we cannot resolve your concern, you may contact the Office of the Privacy Commissioner of Canada (priv.gc.ca, 1-800-282-1376), your provincial privacy regulator, or — where GDPR or a U.S. state law applies to you — your local supervisory authority or attorney general.