What we store, and how to export it

A straight inventory, then how to get all of it out in one file. If you are going to trust a service with government IDs, you should be able to read exactly what it holds.

The inventory#

What is held against your account:

• Identity documents and verification results. The ID images from verification, whether captured through the ID check or uploaded directly, and the verification outcome. Each image's SHA-256 digest is recorded when it is stored.
• Signed releases and other documents. Model releases as signed PDFs, assigned documents as uploaded, compliance forms exactly as they were signed, and the signatures themselves. Each release records when it was signed and from what IP address.
• Depictions, with a compliance copy. A depiction entry is the content's title and type, every address it is published at, the SHA-256 of your original, an optional thumbnail, and a reduced copy of the depiction itself, which 28 CFR 75.2(a)(1)(iii) requires the records to include. A depiction keeps up to fifty addresses, and you can add or remove them at any time. Images are downscaled in your browser before upload; video is the rendition you choose to send (under 500 MB; quality does not matter). The copy is hashed on our side when it lands, and both digests are recorded. More on the digests below.
• Attestations, with timestamps. Your ID-examination attestation on a scene or content log entry is stored with the time it was made and the IP address it was made from.
• Shoot-day verification. Where used: the on-set photo of the physical ID and the video consent recording, both hashed at upload.
• Generated artifacts. Your 2257 statement, cross-reference indexes, monthly acquirer reports (Producer, Studio and Enterprise plans), and export archives, each with digests recorded at generation.
• An audit log. Exports, uploads, and deletions are recorded with who did them and when.

What is not stored: your originals, and your card details. Your published content lives wherever you published it; the platform holds its address, its digest and a reduced copy, not the master file. Payments run through the payment processor, and card numbers never touch these servers.

Identity documents and signed records are stored encrypted at rest, and everything moves over encrypted connections. Sensitive personal fields, such as dates of birth, carry a second layer of application-level encryption on top of storage encryption.

Compliance records are also kept structurally separate from ordinary account data: their own tables, their own storage areas. That separation is a requirement of the record-keeping regulations, not a design preference; the records system has to be identifiable and producible as a system.

How integrity is established#

A SHA-256 digest is computed and recorded for every compliance upload: ID images, signed documents, releases, on-set photos, consent videos. Records stored before hashing covered every path were backfilled from the stored bytes, so every record now carries its digest.

What a digest proves is narrow and useful: the file retrieved later is byte-for-byte the file that was recorded, or it is not. It does not prove a document is genuine; it proves it has not changed since it entered the system.

A depiction carries two digests. The first is computed in your browser from your original file when you add the entry and attests that you recorded a specific file's fingerprint at a specific time. The second is computed on our side from the compliance copy after it is uploaded and verified against the size and type you declared; it is what an inspector checks the produced copy against. Depictions recorded before copies were required carry only the first and show as "No copy on file" until you add them again with the file. That works on a closed scene too: you are asked for a short statement of why the depiction is being added after close, and it is recorded word for word. The copy and its digest join the live record at once. The sealed package does not change on its own: once the record has moved, the production's archive page offers to reissue it, and the package and certificate you already had stay on file, marked superseded. Correcting a closed scene covers that.

Digests are visible on each depiction entry, and each monthly acquirer report shows its digest with a copy button so a recipient can verify the file they were forwarded.

The cross-reference index#

If someone inspects your records, this is what they navigate by: an alphabetical map from every performer to the content they appear in. The regulations require the records to be retrievable by performer name, including every alias, which is why it is alphabetical and why the aliases matter.

Each entry carries the performer's legal name, every other name they have worked under, their date of birth, and the scenes they appear in: scene code, title, date, and the published locations of the content. One entry, roughly:

> Doe, Jane — aliases: Jane D., JD — DOB 1998-04-02

> Scene PROD-2026-368 #1, "Test", 2026-07-28 — published at the listed content addresses.

The index is generated from your scenes and content records at export time. It can only contain what you logged: a piece of published content that never became a depiction entry is absent from the index, and the index is the first thing a reviewer reads. That is the practical argument for logging content as you publish it, not at the end of the quarter.

What solo creators export#

Solo accounts do not generate the production archive; solo records are a content log, not productions. The solo export surfaces are:

• The content log CSV, from the Solo Content dashboard: every entry with its log code, public verification address, platform, content address, production date, performer names, attestation time, and each entry's depiction digests.

The monthly acquirer report is a producer-plan artifact (Producer, Studio and Enterprise), kept under Acquirer Reports on those accounts; it is not part of the solo export.

Exporting the archive#

The archive is the producer deliverable: what you hand to counsel, a processor, or anyone with a legitimate reason to inspect a production's records.

It is generated by finalizing a production, and finalizing is one-way: the production is sealed. No new scenes go into it, and its details stop being editable. It is the closing of the file, not a report you run casually. Sealed is not frozen: when the record is corrected afterwards, the archive page offers to build a new package and certificate from the record as it stands, and the previous ones stay on file, marked superseded.

1. 1

   Generate

   Finalize the production from its page. Everything is assembled while you wait: documents fetched, forms rendered to PDF, the index built, the ZIP written. Stay on the page until it completes.

2. 2

   Download

   The archive then lives on the production's archive page for as long as the production exists. Each download issues a fresh short-lived link, so download links are not shareable; the page is where you return for the file.

Inside the ZIP:

• One folder per scene, with one folder per performer inside it: their documents, their ID verification images, and their shoot-day verification where used.
• A depictions folder per scene, holding thumbnails and metadata, and the compliance copies themselves while the package stays under 200 MB; larger copies are listed in the manifest by digest and downloaded one by one from the depiction.
• model-releases/: every signed release PDF, with a manifest listing each file's SHA-256 digest and signing date.
• acquirer-reports/: every monthly report to date, PDF and JSON, with its own digest manifest.
• cross_reference_index.json: the index described above.
• producer-attestations.json: your attestations, with timestamps.
• manifest.json: the inventory of everything above.

The manifests are what make the archive evidence rather than a folder of files. To verify any individual document, compute its SHA-256 and compare it to the manifest entry; a match means the file is byte-identical to what was recorded. The ZIP's own digest is computed the moment the archive is generated and recorded against the archive, outside the ZIP, necessarily: a file cannot contain its own hash.

When to produce one#

Finalize and export when a production's work is genuinely complete, when a processor or counsel asks for records, and always before cancelling a subscription. The five minutes it takes is the difference between "here is everything, with digests" and reconstructing a records request from a closed account.