Data handling

Where your footage goes

Written from the code rather than from a template. The two lines under this say which passages were read against the code, and when; where something is unresolved or imperfect, the page says so rather than leaving it out.

Last checked 30 September 2026: the last date the whole page was read against the code.

Newer than that date, and read on their own, not as part of a reading of the whole page: the passage on signing up, the paragraphs on the card, the payment provider, the records of invoices and the history of what an account was on, the passage on the sample project, the passages on what an account erase deletes and leaves, and the notices and error reports about how V1 itself is running (added 5 October 2026 or after).

What you give V1

• Your account — a name and an email address.
• Signing up, when V1 is open for it — a name, a work email address, a company name, a password (kept only as a one-way hash), which version of the Terms of Service and of the Privacy Policy you accepted and when, and, while sign-up is by invitation, the code you were given. Anyone can type any address into the form: V1 sends that address an email with a link each time the form is asked for it (and again if V1's staff let a refused sign-up through), and holds what was typed until the sign-up is finished or deleted. V1 holds this from the form until the address is confirmed and a card is added, and then it becomes your account. The record of the sign-up stays after that, as the record of where the account came from, with the same details and without the password's hash. V1 compares the address's domain with the sign-ups that became accounts, to start one account for a company, and the card's fingerprint with the cards on file, to start one for a card; a sign-up that is refused for one of those reasons, for an address from a throwaway-mail service or for a code that does not work is recorded with the reason for V1's staff, who can let it through. A sign-up that is not finished is deleted a week after it was last asked for, and never more than 30 days after it was first started, together with the record its card step made at the payment provider; where that record cannot be deleted because the provider cannot be reached, the sign-up is kept and tried again until it can be, so these times are what normally happens. The acceptance of the Terms and the Privacy Policy is kept with your sign-in. A note V1's staff type about who a sign-up code was made for (they can make one whether or not sign-up is open) is cleared 30 days after the code stops working, or when they delete the code.
• Your account's people and brands — who is a member, the role each has and the brands each is limited to; the addresses invited, who invited them and what came of each invitation; and each brand's kit — its name, colour, PNG mark, delivery formats and, if somebody keeps one there, a title-card design. Inviting an address that has no V1 sign-in makes one, holding that address and the name the inviter typed. A week after it was sent, an invitation cannot be accepted or used. If nobody ever set that sign-in's password or signed in, and no other invitation waits for it, it is deleted when its last invitation is withdrawn, or when V1 next sweeps invitations that are a week old. V1 sweeps them when the app starts, when V1's scheduler next runs, when V1 adds an account or a person from the command line, when a set-password link is opened or used, and when invitations are listed, sent, accepted, declined or withdrawn. Until then it stays. A sign-in whose password was set, but which never accepts, stays indefinitely.
• The project — its name, the brand or client, the event date, the venue and city, how long the cut should run, and any notes you write for the team.
• The footage — the video files themselves.
• Optionally — a music track, a brand colour and a PNG mark. Where an account has the agency's mark, a brand's PNG mark is shown, in place of V1's own mark, to anyone who holds a share link to one of that brand's projects.
• Your card, once V1 asks for one — you enter it on a payment provider's own page, never on V1's, so the number and the security code never reach V1. V1 keeps the card's brand, its last four digits and its expiry, a fingerprint the provider gives it, and the provider's references for your account and for what you buy. The fingerprint is kept for one purpose, to recognise the same card on another sign-up; the provider does not always give one, and a card paid with from a phone's wallet may have a different one from the same card typed in (V1 has not tried this against the provider), so it is a check that can be got round, not a guarantee. V1 does not charge a card on its own, including the card added when you sign up. A card is charged when you choose to buy, on the provider's page; when you change what you bought, on V1's own page, after it has told you what the change does and you have said yes; and at each renewal, which happens by itself until it is cancelled. Your bank may show a check of its own when the card is saved. A renewal's charge can include extra projects V1 added to the invoice as they were made, which the owner of the account can turn off, or put a cap on, on V1's billing page.
• Your review — which shots you kept or dropped, any trims and reframes, and the notes you type.
• An approver's answer, if you send a share link — the name and email they type, their verdict and their notes. That identity is self-asserted: it is whatever the person typed, and the record keeps it alongside who you meant the link for, so the two can differ visibly.
• An access request, if you send one — the name, email address, company and message typed. It is emailed to V1's staff; one made on V1's own app, rather than the public site, is also kept in V1's database and is not deleted automatically.

Who in an account sees whose address

• Everyone a project's email goes to sees the addresses of everyone else it goes to — every active member who can see that project — because each message has them all on one line.
• Everyone who can open a project sees who wrote its reviews and notes: a review shows its writer's name, or their address only if they have no name; a note shows the name and the address. They see the name and address an approver typed, too.
• An account's owners and admins see every member's and every invitee's address, on its members page.
• Someone invited sees the name of whoever invited them, or their address if they gave no name — or "V1" when V1's staff did.
• A crew member on a team link sees the producer's name, or their address if they gave no name.
• V1's staff see everyone's.

The sample project

V1's staff can mark one finished project as a sample. While one is marked, every signed-in person, a member of any account, can watch its cut, see its numbered shots and download its exports, and nobody can change it from there. It comes off the list of the account it was made in, and that account's members can no longer open it as a project; V1's staff can. A share link made for it before it was marked keeps working until it ends. Nothing new is recorded for it in anyone's usage or on the usage record; what the usage record already held for it stays, set aside under no account, with the number of the account it was made in kept on each of those rows so that taking it off the sample can put them back. The account it was made in cannot be erased while the project is the sample: V1's staff take it off first, which puts those rows back on the account, and erasing the account then clears the number. Automatic release (below) does not touch it, and V1's staff cannot release its footage while it is the sample. Until V1's staff mark one there is none. V1's staff choose it; nothing in the software checks whose footage it is or who is in it.

Where it lives

On one server V1 runs, in a directory per project and a single database. Not in a data warehouse, not in an analytics product. There is no analytics or tracking of visitors of any kind on this site — no tag manager, no pixel, no third-party script. One outside request is made on every page: its typefaces load from a font provider, which, like any web server, sees the visitor's address. Reports of V1's own faults, if V1 has switched them on, are a different thing and are listed below.

Who else sees it

These are the only third parties any of your material reaches, and what each one gets.

Text messages and chat notifications are built but switched off; nothing reaches those providers unless V1 turns them on and says so here first. Error reports are built and switched off: the row above describes what a service would receive, and until V1 switches it on, nothing is sent to anyone.

The notes, specifically

Most review notes do not name an edit a machine can make, so they used to reach the producer as text and nothing else. V1 now sends each note to a language-model provider to be read back as one sentence and labelled. What that means for you:

• Only the note text and those four numbers leave the server.
• The provider states that content sent this way is not retained by default, and that retained data is not used to train models without permission.
• The exception, and it is worth knowing: content their automated safety systems flag may be kept for up to two years. No arrangement removes that.
• A reading can change the recut your own review asks for: when it reads a note of yours as one edit to one shot of the cut you watched, the recut makes that edit, and the page shows what was done and which reader read it. Any other reading is only shown to a person, who decides. A model reading of an approver's note, or of a note from an earlier round, is never built in; such a note reaches a cut only when the producer accepts it.

Backups

The database and the records are backed up nightly. The footage is not — nor are the proxies, thumbnails, filmstrips or the render cache, which are either large or rebuildable. So a backup holds what was decided and made — the records, the cut, its review copy and exports, your music and sound bites, and V1's readings of what each clip shows — and not the originals. Fourteen nightly copies are kept by default, on the same server as the live data.

Getting rid of it

Three different things, and they are not the same:

• Archive — puts a finished project out of the way. Deletes nothing, keeps the name reserved, and a direct link still opens it.
• Release the footage — deletes the original clips, their playable copies, the sound bites, the render cache and any copies uploaded straight to storage. What was made from it stays: the cut and its review copy, any exports, and your review. After this the cut cannot be rebuilt from your originals, and the project takes no more changes, footage or shorter versions; a new edit would need the footage sent again, to a new project. V1's staff can release a delivered project's footage, and keep any project's longer.
• Erase — deletes the project record, its uploads, reviews, runs, notes, share links and notification numbers, the whole project directory, and the copies held at the storage provider - so long as V1's server still has that provider set up; if it does not, an erase cannot reach them and deletes the only record of what was there. It frees the name for reuse and it cannot be undone.

Automatic release

V1 can release footage on a clock of its own, and it runs only once V1 switches it on. Until then, footage stays until V1's staff release it or the project is erased. When it is on (every day counted below is counted by V1's server clock):

• The last day kept is 30 days after a project's last delivery, or 60 days after the last activity V1 records on a project that is not delivered - one never delivered, or reopened or taken back into work after a delivery. Activity is what the project's history records - an upload, a review or a new cut, for instance. Looking at a page records nothing.
• V1 emails that date, 7 days before it, to every active member of the project's account who can see the project - the people who get its other emails. Nothing is released unless that email was accepted by V1's email provider, at least 7 days before the release, and while automatic release has stayed on since - switched off and on again across one of its regular checks, it sends a new email first. If the provider refuses it, V1 sends it again the next day, up to 7 sends in all, then V1's staff take it up. If no email can be sent at all - email not set up on V1's server, or nobody in the account able to see the project to send it to - none is sent and nothing is released. Either way the footage stays, and the project page shows no date until one has been accepted. Accepted means the provider took it, not that it reached an inbox.
• The release comes after the end of that day, wherever you are: no earlier than the start of the second day after it, in UTC.
• Nothing is released while V1 is working on the project or a clip is still arriving, and a project holding no footage has no date. A release that did not finish is tried again the next day, including one V1's staff made since automatic release existed, which needs no new email because they chose it; one the storage provider still will not answer for is left for later, and one V1's staff made before automatic release existed is left to V1's staff.

One honest detail about erasing: V1's own history of a project is stored against that project, so erasing it removes that history too. A single line naming what was erased, and who did it, is written to the operator's log. What stays is the account's usage record: one line saying the project reached its first cut, if it did, and one line for each clip stored, processing run, download of footage from the storage provider, message sent, call to read review notes and day's storage measure, each with its time, its quantity and — from the version of V1 that brought accounts and brands on — the brand the project was for. It is detached from the project, and nothing on it names the erased project.

Payments are the same kind of exception, once V1 takes payment. V1 keeps one line for each invoice the payment provider reports paid on an account: the provider's reference for the invoice, the account's number, the provider's references for the customer and for what was bought, whether the payment was made with a live or a test key, the amount and its currency, the period the invoice covered, the time the provider gives for the payment and the time V1 recorded it, which of V1's offers it was for and in which version, and the provider's reference for the event it was read from. When V1's staff erase an account (above), V1 keeps these lines, because they are a financial record, and takes the account's number and the provider's reference to the customer off them. That is not the same as making them anonymous: what is left still says what was paid, when to the second, and the provider's references, which the provider can tie to a person. A charge V1 has queued for a project that was extra to what the account buys is erased with the account, and V1 deletes the customer at the provider; what that does to a charge already on an invoice V1 cannot say from its own code. A charge for a project is not taken back if the project is erased afterwards.

V1 also keeps, for each account that pays, a short history of what the account was on and from when: which of V1's offers and in which version, how many projects a period holds before an extra one is charged for, the period it counts from, and the time each of those changed. It is kept so that a charge for an extra project is worked out against what the account had when the project was made, and not against what it has later. It holds no person's details, and it is erased with the account, as the charges queued for projects are. V1 also keeps the email address of the account's owner that it last gave the payment provider as the address for receipts and reminders; it is erased with the account too. It is not removed when a person leaves the account or is erased as a person: V1 replaces it with the new owner's address, and otherwise it stays with the account.

Erasing a project does not reach its brand. If somebody kept the project's title-card design for the brand, that design stays with the brand after the project is gone — the event's own title words in it included — until somebody takes the cards off the brand, which deletes them, or uses “Use these cards for” on another project, which writes over them. No button on an account's own pages deletes an account or a brand. A brand's mark file is deleted from the brand when somebody removes it or puts another in its place. Each project made from the brand keeps its own copy of the mark and of the title-card design. On the project somebody can replace or remove the mark; the cards can only be saved over in the card editor or taken off the renders, and taking them off leaves the design saved on the project, its title words included, until it is saved over or the project is erased. The nightly backups keep the copies that were, until those backups age out.

A member an owner or admin removes is taken out of the account; their sign-in stays in V1, outside it. The invitations they sent that were still waiting are withdrawn, and the share links and team links they made and the notification channels they added are ended, unless whoever removes them chooses to keep those.

V1's staff can erase an account, on request or when V1 decides to; nothing erases one on a clock. They type the account's name and a reason, and V1 refuses while a run is working on one of its projects. It erases every project of the account as above, with the same exceptions, the brands and their mark files, the members and invitations, the record V1 keeps of what the account is set up to do and of any exception V1's staff made for it with the reason they typed, the history of what V1's staff did to it, and its place in the queue. It also erases what V1 keeps of the account's payments: the record of the card it saved (its brand, last four digits and expiry, and the provider's fingerprint of it); the billing events the provider sent for it, in full and as the one line each leaves; the provider's references for its customer and for what it bought; the charges queued for its extra projects; the history of what it was on and from when; and the email address last given to the provider for receipts. Before any of that, V1 asks the payment provider to delete the customer there; what the provider then keeps, V1 cannot say. If V1 cannot reach the provider, the erase stops and is run again. Where the customer is at the provider in a mode V1's server holds no key for, V1 refuses, unless its staff accept deleting that customer by hand in the provider's own dashboard, and then the record of the erase (below) holds the provider's reference for it. The invoice lines (the paragraph on payments above) are the exception: they are kept, as the list below says. It also erases the record of the account's sign-up, with the details it held and the reasons V1's staff or V1's rules recorded on it. The acceptance of the Terms and the Privacy Policy goes with the sign-in of each person the erase lets go of (next paragraph); a person who belongs to another account keeps their own. It cannot be undone.

A person whose only account it was, and who is not V1 staff, loses their sign-in: the address, the name and the password hash are deleted, with their sessions and links. If another account's records still name that person, such as a project they made in an account they have since left, the sign-in stays as a row that holds its number, the date it was made, an old label of its kind (customer or admin) from before accounts had roles, a made-up address of the form erased-number@erased.invalid that no mail can reach, no name, a password nobody has, a mark that it is switched off, a mark that its password must be replaced and a mark that it is not V1 staff. The name and address that other account's review notes, music records and project rights acknowledgements took down when that person acted in them are cleared in the same step. What the person typed there in their own words, and the music rights confirmation and the project rights acknowledgement stored in that project's own files, which name who gave them, stay with that project until it is erased. People who belong to another account, V1's staff, and anyone with an invitation waiting elsewhere keep their sign-ins and lose only their membership of this account.

What an erase leaves, and for how long:

• The usage record, detached from the account and from its projects, as for a project: nothing on it names either. It has no end date.
• The invoice lines, one for each invoice the payment provider reported paid, as the paragraph on payments above lists them, with the account's number and the provider's reference to the customer taken off. They are a financial record: they have no end date (V1 has set no time after which they are deleted, and nothing removes them), and detached is not anonymous.
• The highest number each of accounts, brands and projects has ever had, so that no number is given twice. Numbers only: no name and no address.
• The operator's log. One line for the account, naming its short name and number, what was deleted and the address of the staff member who did it, and one for each of its projects, as above. V1's software does not remove lines from that log, and V1 has not set a time after which they are.
• One record that the account was erased: the account's name (a person's name, where the account was one person's), the date, the reason V1's staff typed, the address of the staff member, and counts of what went. Where V1's staff accepted that something at a provider could not be deleted, it also holds what was left, by the provider's own reference, so that it can be deleted by hand; a provider can tie that reference to a person. The reason is typed text and can name a person. This record has no end date: V1 has not set a time after which it is deleted, nothing removes it on a clock, and no page in V1 deletes it. V1's staff can read it.
• The nightly backups keep the copies they took until those age out.

An erase also cannot reach what has already left V1's server. Emails V1 sent stay with the email provider and with whoever received them; notices sent to V1's staff stay in the team chat service when it was on; review notes sent to the language-model provider are kept as that provider says above; and an export somebody downloaded stays wherever they saved it. At the storage provider, V1 deletes each object by its name. If that provider's bucket keeps earlier versions of an object it has deleted, which is a setting of the bucket that V1's software neither sets nor reads, those versions are not removed by an erase.

What V1 does not do

• Nothing you send is used to train any model.
• Nothing is sold, and nothing is shared with anyone beyond the providers named above, each for what its row says it receives.
• No advertising, no profiling, no tracking across sites.

If this page is wrong

Tell V1 and it gets corrected. This page is maintained against the code, and it is meant to be checkable — if something here does not match what you observe, that is a defect worth reporting.