PTD CAPITAL LLC / OPERATING PROTOCOLHypermega cultural-data transfer checklist
PTD-ARC-2026-HYPERMEGA-02 · 16 October 2026 · Version 1.0
Prepared by Idris Vale · Open · Proposed operating controls
Release boundary
A cultural-data transfer includes the selected technical files, their descriptive records and the applicable permission snapshot. The package is a defined release, not an unrestricted copy of the programme's working storage. Each release must identify its intended recipient, purpose and version.
The procedure below applies to the proposed gallery-sourcing and capture workstream. Facility planning and participant research have separate records. No research data should enter a cultural dataset merely because it is technically compatible with the same storage system.
Before intake
| Check | Evidence retained | Unresolved outcome |
|---|
| Work and creator identity | Stable work reference, attribution and source contact | Hold record for clarification |
| Authority and use | Rights-holder file and permitted-use schedule | Exclude from release perimeter |
| Territory, duration and restrictions | Explicit fields linked to the authorisation version | Do not infer an unrestricted use |
| Capture plan | Required views, source format, settings and acceptance criteria | Return for technical specification |
During capture and transformation
Assign each source file a stable identity and record the capture event. Keep the source file separate from corrected, resized or transformed derivatives. A derivative record identifies its inputs, the operation applied and the resulting file. An operator's visual approval is retained alongside technical checks; it does not replace them.
Errors should remain specific. A file can be intact but incorrectly attributed, technically consistent but outside the use permission, or authorised but unsuitable for a particular output. The record should name the failing condition and the responsible reviewer. A general approved flag conceals these distinctions.
Release package
The manifest contains the release identifier, creation date, file list, file hashes, record versions and referenced permission snapshot. Reconcile the manifest against the actual package immediately before release. Confirm that the recipient's intended use matches the recorded scope. A mismatch stops the affected portion of the transfer until the scope is resolved.
Retain a copy of the exact package and the approval record. A later metadata correction creates a new version with a stated relationship to the earlier release. The release log must make it possible to identify who received the superseded package and what corrective communication is required.
Restore test
A release is not fully archived until an authorised operator can retrieve it from preserved storage, compare it with the manifest and locate the supporting permission record. Record the test date, operator, result and any exception. The restore procedure should be usable by a colleague who did not prepare the original package.
Where a dependence cannot be preserved, record the limitation plainly. A proprietary capture setting, missing software version or unavailable external service should not disappear from the record because the exported image still opens.
Correction and restriction
On discovery of an attribution error, technical defect or permission restriction, identify the affected work records and release versions. Preserve the original release record while changing its current availability. The correction file states the issue, decision owner, replacement package and recipient follow-up. Avoid overwriting the evidence that explains how the earlier release was assembled.