How Transfer General Works

This page explains how Transfer General executes a single data transfer, step by step.

It assumes you already understand why Transfer General exists. What follows is strictly execution reality — where data goes, how it is protected, and what evidence is produced.

Execution Model (One Object)

Transfer General operates at the object level. Each object is handled independently, with its own integrity checks, encryption, retries, and transfer record.

All execution components run inside the customer’s cloud accounts. Data never enters infrastructure owned or operated by Server General.

The object lifecycle uses four clearly defined locations:

• Source bucket: where the object is originally written
• Staging bucket: encrypted holding area in the source cloud account
• Landing bucket: encrypted intake area in the destination cloud account
• Destination bucket: final customer-facing storage location

Step-by-Step Execution

1. 1 Source object creation

   An object is written to a customer-controlled source bucket in the customer’s source cloud account.

   Transfer General does not intercept application traffic and does not require changes to how applications write data.

2. 2 Integrity baseline capture

   Before any modification, Transfer General computes a checksum on the plaintext source object.

   This checksum establishes the baseline used to verify integrity after transfer.

3. 3 Object-level encryption

   Transfer General encrypts the object at the object layer, not merely in transit.

   • Encryption uses keys managed in the customer’s cloud Key Management Service (KMS)
   • If a KMS is not already configured, Transfer General provisions and configures one
   • Encryption and key usage events are captured during execution
   • The object remains encrypted whenever it moves between cloud accounts; unencrypted data is never transferred across cloud boundaries.
4. 4 Staging inside the source cloud account

   The encrypted object is stored in a staging bucket within the customer’s source cloud account, without leaving the customer’s compliance boundary.

   This staging bucket is part of the customer’s environment and does not expand compliance scope.

5. 5 Cross-cloud transfer

   The encrypted object is transferred from the staging bucket in the customer’s source cloud account to a landing bucket in the customer’s destination cloud account.

   Transfer General controls and monitors the cross-cloud transfer process.

6. 6 Decryption and integrity verification

   In the landing bucket in the customer’s destination cloud account:

   • Transfer General decrypts the object using the customer-controlled key
   • A checksum is recomputed on the decrypted object
   • The checksum is compared to the original source checksum
   • The object proceeds only if integrity verification succeeds.
7. 7 Failure handling and retry

   If a transfer fails:

   • Transfer General resumes using offset-based re-transfer
   • Only missing data is retransmitted
   • Retry behavior is deterministic and recorded
   • If integrity verification fails, the object is not promoted to the destination bucket and re-transfer is initiated.
8. 8 Finalization

   Once integrity verification succeeds:

   • The object is written to the destination bucket in the customer’s destination cloud account
   • The object is removed from the source bucket as part of the controlled transfer process
   • The transfer is considered complete
9. 9 Transfer record and attestation

   As execution proceeds, Transfer General emits structured audit events bound to the object being transferred. These events are accumulated into an object-level transfer manifest that travels with the object through encryption, staging, cross-cloud transfer, verification, and finalization.

   After final integrity verification:

   • The manifest is finalized
   • The manifest is cryptographically sealed
   • The manifest is written to immutable, append-only storage
   • Transfer General cryptographically signs the finalized manifest, attesting that it accurately represents the transfer executed by Transfer General. This attestation applies only to transfers executed by Transfer General.