How Transfer General works

Everything you’d need to build. None of what you’d have to own.

TG gives you the pipeline, the operational visibility, the exception tracking, the object-level evidence, and the signed attestation — deployed in your own accounts, without turning your team into the long-term owner of a custom evidence system.

The same five capabilities · two very different commitments

Build it yourself

Your team becomes the long-term owner of a custom evidence system.

01

Cross-cloud pipeline

You own: wiring STS / DataSync + OIDC federation per direction — and re-fixing it every time a cloud API drifts.

02

Operational visibility

You own: building and running the dashboards, status, and diagnostics — forever.

03

Exception tracking

You own: detecting and triaging failed, stalled, authorization-required, and overwrite cases.

04

Object-level evidence

You own: a per-object integrity record across clouds.

no single record covers this today

05

Signed attestation

You own: signing, WORM retention, and independent verification an auditor will trust.

Every capability above is yours to build, operate, and own — through every cloud-API change, indefinitely.

Deploy Transfer General

The same system — running in your own accounts, encrypted with keys only you hold.

✓Cross-cloud pipelinerunningTrace one object end-to-end ✓Operational visibilityrunningSee transfers in flight ✓Exception trackingrunningSee an exception caught ✓Object-level evidencerunningSee the chain-of-custody log ✓Signed attestationrunningSee the signed record

Get all this — without turning your team into the long-term owner of a custom evidence system.

Each capability is live in this deployment — follow any one through to the real artifact it produces.

§the_proof in view · not behind a link

Here is the artifact itself — one object’s signed attestation record, produced automatically at transfer completion. Every value is independently verifiable against the cloud provider’s KMS without contacting Server General.

tg_id

26e0e72027abd4501c4bf5ced83dbb85b1e6b4fc70495b662922fd839b12c391

✓

Verification passed

6 PASS · 0 WARN · 0 FAIL · COMPLETE — ATTESTED

Object

patient001_study002_series05_img010.dcm · 256.0 MB

Route

AWS (us-east-2) → GCP (us-central1)

Integrity — SHA-256 (source = destination)

7756cef737283c3232…2e1fad ✓ hash_match = true

Object encryption

AES-256-GCM · OpenSSL FIPS Provider, CMVP #4985 (FIPS 140-3, Level 1)

Signature

EC_SIGN_P384_SHA384 · ECDSA P-384 / SHA-384

Immutability anchor

immudb tx_id 1648 · Merkle-chained · WORM-retained

How the integrity check works

The object's hash is computed on its contents before encryption. The object is written to the destination only after its hash is recomputed there and matches the source. If the hashes don’t match, the write is aborted and the transfer fails.

Representative — sample Meridian Health data. See the full attestation record

Five capabilities. One deployment, in your own cloud accounts.

Request a PoC See what it costs