# Storage your own cloud cannot read, lose, or silently alter.

> DataPrism sits on top of the cloud you already run: one pipeline applies the property to that storage, so what you can prove about your data changes while your architecture stays exactly as it is.

Source: https://dataprism.co/product

## Encrypted before upload. Dispersed with redundancy. Proven in public.

The property starts with client-side encryption: keys are derived on your side, and what leaves is already unreadable. Each stage below turns one assurance from a provider's promise into a behaviour of the data itself, which is what makes it demonstrable to a customer, an auditor or a regulator. Where encryption before upload is already in place, start with

## A sovereign overlay, not another silo.

You keep your object storage providers. DataPrism composes them into something none of them can offer alone: storage where a provider still holds your bytes but can no longer read them, and no longer decides whether you keep them. Replacing your providers would also mean replacing your contracts, your regions, and your compliance posture. The overlay leaves all three where they are, which turns an infrastructure decision into a decision your security and compliance teams can take on their own.

## Your provider cannot read it. That is one problem of three.

Encrypt before upload with a key you hold, and your provider is blind to your data. That is real, and it is where our own pipeline starts. Three things stay exactly as they were: it still holds all of it, it can still stop you reaching it, and you still have nothing an auditor can check without you.

## Enforced by consensus, not by an operator.

Any guarantee an operator enforces, an operator can quietly break. So integrity here does not depend on anyone's good behavior, including ours: the anchored root index never grows with your data, and every fragment is content-addressed, so any alteration is detectable end to end. When a customer or an auditor asks how you know nothing was altered, you show a proof anyone can check, not a report only your provider can produce, and answering them does not mean opening a ticket with anyone.

## What lands in your stack.

- **Your architecture stays as it is**: Your providers stay: no infrastructure project to fund.
- **A single compromise is not enough**: Encrypted fragments across the providers you configure: reaching one estate is no longer reaching your data.
- **You survive losing a provider**: Provider outages and refusals stop being events you plan around.
- **One check, at any volume**: One fingerprint, whatever the volume behind it: the same single check at any scale.
- **You would know if it changed**: Every fragment content-addressed: alteration surfaces instead of passing unnoticed.
- **Encryption your team does not write**: A TypeScript SDK: no cryptographic plumbing to build or defend in review.

## Asked before every demo.

### Do we have to migrate our data?

Your providers, regions and contracts stay exactly as they are, and there is no platform to move to. What passes through the pipeline is the data itself, and there are two ways to start: apply it to everything written from now on, which leaves what already sits there untouched, or bring an existing perimeter through once, which rewrites those files as fragments into the same accounts. Either way it is a change one team ships, not an infrastructure program to budget for. The set of destinations is yours to pick and to change: several accounts at one provider, several providers side by side, your own on-premise storage, or any mix of them. Anything that speaks the S3 API is a destination today, and adding one later is a configuration change, not a second integration. The overlay is described in What it is, above.

### We already encrypt client side. Does DataPrism replace that?

No, and it does not ask you to unwind it. The SDK encrypts on your side too, so an object you hand it already encrypted travels the pipeline as your ciphertext. What changes is everything after encryption: how many places the fragments land in, and what a third party can check. The section above sets out what encryption alone leaves open.

### What actually lands on the public ledger?

A sealed index, and nothing else: the map that puts your fragments back together, encrypted with a key we never receive. No content and nothing readable ever lands there, so anyone can check your integrity claim without you publishing anything about your data. What each actor can see, and what none of them can, is laid out in the security architecture overview.

### What happens to our data if DataPrism stops?

Your files stay in your own accounts, and the key stays derived on your side, so recovery holds without us. Reconstruction runs client side from the fragments your providers hold and from the index on the public registry, and the SDK reads that index through an interface any public node can serve. The recovery path is a property of the design rather than a commitment we make, which is what the security architecture overview sets out.

### Which storage can it compose?

Whatever object storage you operate, wherever it runs: AWS, GCP, Azure, or on-prem. The pipeline is the same across all of them, and no part of your integration changes when the mix of providers does.