Data export: Data, permissions, and operations

Defines an asynchronous, authorization-safe account or organization export with a fixed snapshot, explicit scope, auditable lifecycle, protected download, expiry, and deletion behavior.

Package status: reference context ready for human review. The contract and test scenarios are complete, but no claim is made that an adopting implementation has passed them.

Decision

Create exports as immutable jobs authorized both at request time and at download time. Capture a declared snapshot boundary, produce a documented manifest, encrypt the artifact, and expire both artifact and link independently.

Scope

• Export request, scope resolution, snapshot, generation, manifest, delivery, download, expiry, cancellation, and audit.
• Personal and organization exports with field-level and tenant authorization.
• Operational limits for size, concurrency, retries, and retention.

Outside this block

• Determining every jurisdictional portability obligation.
• Backup restore or unrestricted database dumps.

Contract

• The requester chooses an allowed scope; the server resolves it to tenant and subject predicates that each exporter must enforce.
• The job records policy version and snapshot boundary so later permission changes cannot silently expand content.
• Download rechecks current access and, for sensitive exports, requires recent authentication.
• The archive contains a machine-readable manifest with schema version, generated time, scope, files, record counts, and checksums.
• Signed download URLs are short-lived, single-audience, and do not replace application authorization.
• Cancellation prevents undispatched work and removes completed artifacts according to the deletion workflow.

Implementation guidance

• Use a job state machine: queued, running, ready, failed, expired, cancelled.
• Stream records in bounded pages under snapshot semantics and write encrypted multipart output.
• Keep artifact keys opaque and tenant-scoped; avoid email addresses or filenames containing personal data.
• Apply row and field filters in each data adapter, then reconcile counts against the manifest.

Failure handling and safeguards

• A retry resumes or restarts under the original snapshot and scope; it must not append duplicate archive members.
• If authorization is revoked before download, deny access and schedule artifact removal.
• If one required adapter fails, mark the export failed rather than distributing a silently partial archive unless partial exports are an explicit product type.

Verification and operations

• Measure queue time, generation duration, bytes, adapter failures, count reconciliation, expired-without-download, and deletion lag.
• Audit requests, state changes, successful downloads, access denials, and artifact deletion without logging exported content.
• Run restore/open/checksum drills on generated fixtures.

The executable-looking examples in this package are fixtures and acceptance contracts. Run python tools/validate.py from the collection root to check package structure and metadata; then implement and execute the scenarios in the target repository.

Adoption assumptions

• Names and numeric values in example.yaml are an adoption profile, not universal defaults.
• The adopting team must map actors, data classes, error vocabulary, and ownership to its system.

References

• No external normative source is required; this package defines a project decision.