Preservation and exit strategy

A record consists of plain files: a manifest.json describing the RTI model and tile pyramid, the tiles (lossless WebP for .ptm and .rti data, PNG in records published before WebP, JPEG for relight data) and a preview image. Member uploads are stored in Cloudflare R2 object storage and their catalogue rows in a Cloudflare D1 database. Curated records added by the maintainers are processed locally, kept in the maintainers' own archive together with the original captures, and published as static files.

The original capture files of member uploads are converted in the uploader's browser and are not transferred to OpenRTI; the record carries a digest of them instead (see Integrity).

A published data version never changes. Reprocessing or new data creates a new version; the record's page lists its version history with dates and change notes, and each version has its own link (…/id/rti-0001/v2). A link to a version that is no longer the current one is never redirected silently: the page says which version it holds.

OpenRTI intends to keep published records available for at least ten years from publication; if the service closes, the collection will be offered to an academic repository.

• Every uploaded file is hashed (SHA-256) when it is written; the storage service's own checksum is recorded as well.
• The source digest (name, size, SHA-256 of the original capture file or relight folder) is published in the record, so anyone holding a file can check that it is the one the uploader declared as the source. The digest identifies the file; it does not by itself prove that the published data was made from it. It is computed in the uploader's browser and cannot be checked by OpenRTI.
• A nightly fixity scan compares the recorded checksum of a batch of stored files with what the storage service reports, oldest-checked first, so the whole store is revisited in a cycle. A further small batch is read in full each night and its SHA-256 compared with the one recorded at upload. Mismatches and missing files are logged and reported to the maintainers.

• Catalogue snapshot: every seven days the service's tables (records, versions, persistent identifiers, file checksums, collections, record editors, audit log, vocabulary, roles, saved views, and each account's display name, ORCID iD and role; no e-mail addresses or sign-in data) are written as a private JSON snapshot to a separate storage prefix; the newest thirty are kept.
• Artefact data: stored redundantly by the object storage provider; curated records exist a second time in the maintainers' local archive with their originals.
• Off-site copy: every week a copy leaves Cloudflare for a separate storage service: each published data version once, as an archive with the checksum of every file (checked against the database before it is written, and one archive is read back and checked on every run), and the whole database, encrypted with a key that only the project holds. Database copies of the last twelve weeks and of the last twelve month-ends are kept; the archive of a record that is withdrawn is removed ninety days later.

If OpenRTI closes, nothing here is locked in:

• Every record's data is plain files in documented formats (JSON manifest, WebP, PNG or JPEG tiles); each record's page states the RTI model, tile layout and source digest.
• The catalogue is a database whose records the public API serves as JSON (/api/artifacts, /api/artifacts/<slug>), and the weekly off-site copy holds the whole database; the pages and the viewer are static files that any web host can serve.
• The viewer and the processing pipeline are MIT-licensed, dependency-free software; site texts are CC BY 4.0; a record's structured details are CC0 1.0 and its descriptions CC BY 4.0. Artefact data keeps the licence stated on each record.
• The maintainers' intention is to hand the collection to an academic institution or repository rather than let it disappear; owners can download their records' information from their account page, and the data files stay readable at their public addresses.

Each record has a persistent link (openrti.org/id/rti-0001) that citations use; it does not change when the record's title or information is corrected, and its number is never given to another record. A record that is withdrawn keeps its link, which shows its title, data creator, dates and the reason for withdrawal. When a record has several data versions, each also has its own link (…/v2). OpenRTI does not assign DOIs; the persistent link is the citation's locator. A record that already carries a DOI (for example from an earlier publication of the data) shows it.

• The off-site copy is weekly: work published since the last copy exists only at Cloudflare until the next one.
• The nightly scan relies mostly on the storage service's checksums: only a small batch of files is read again in full each night, so a complete re-hash of the store takes many nights.
• Files stored before checksums were recorded get a baseline on their first visit; that first visit is not a verification.