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, as references. A depiction entry is the published address of the content, its type, an optional digest, and an optional thumbnail. The content file itself is never uploaded and never stored. More on the digest 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, 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 content, and your card details. Content lives wherever you published it; the platform holds references to it. 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.

One deliberate exception: a depiction is a reference to content hosted elsewhere, so the platform never has the file to hash. Its digest is computed in your browser, from your local copy, when you add the entry; nothing is uploaded. That digest attests that you recorded a specific file's fingerprint at a specific time, which is exactly as strong as it sounds and no stronger.

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, generated for every active account on the 2nd of each month and kept under Acquirer Reports.

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 archived and locked. It is the closing of the file, not a report you run casually.

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. The content itself is a reference, as everywhere else.
• 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.