2. The Verae DataCube Server Solution

2.1. Purpose

A Verae DataCube Server Solution is the on-premises or customer-hosted assembly that gives an organization a place to put sensitive digital objects, a way to move them, a way to prove when they first existed, and a way to show an examiner that the bits have not been silently rewritten.

It is a server solution in the sense that an organization runs (or has run for it) a set of cooperating services: encrypted storage, a message fabric, a public-key directory, a timestamping link to Verae’s central service, and an archival export path. It is not a single binary, and it is not a cloud folder with a padlock icon.

2.2. The DataCube as a container

A DataCube is a customer-controlled container for digital objects and for the metadata that makes those objects examinable. Typical contents include:

  • the object bytes (a message body, a document, an image, a log extract, an AI prompt and completion, or any other digital media);

  • private metadata that the organization needs but does not necessarily share (internal identifiers, matter numbers, legal-hold flags);

  • attached files that travel with the object;

  • an internal chain of hashes so that the cube itself has a history — each new write names the previous write.

Verae’s public product description is consistent with this split: records stay in storage the customer controls; Verae seals a fingerprint. The server solution is the machinery that makes that split operational rather than rhetorical.

2.3. Two information states, one operational picture

Classical security training divides information into data in transit and data at rest. The DataCube Server Solution is built around that division.

In transit, the problem is an untrusted network. Messages must be readable at the destination and nowhere else along the path, yet the path must still be able to deliver them. Chapter 4 treats that problem in full: point-to-point encryption, visible routing, honest-but-curious brokers.

At rest, the problem is an untrusted disk, an untrusted backup operator, and an untrusted replica. Bytes must be stored so that a host who does not hold keys sees opaque blocks, and so that a restore can prove it brought back the same blocks that were written. Chapter 5 treats that problem in full: IPFS content-addressed ciphertext, Peergos hash verification, tamper-evident restore.

A third problem sits beside those two: time. Storage and transit prove confidentiality and integrity of what was stored or sent. They do not, by themselves, prove when it first existed, or that a later rewrite is not being offered as the original. Timestamped receipts (Chapter 6) and the cross-blockchain timestamping architecture (Chapter 8) address that.

2.4. What “server” means in practice

In a typical deployment the organization runs, or links:

  • a Peergos instance (or equivalent cryptree client) that writes encrypted, content-addressed blocks;

  • an IPFS layer that stores and replicates those blocks by hash;

  • a message fabric (NATS in the reference deployment) that carries HPKE-sealed bodies with destinations in the clear;

  • a public-key directory so every endpoint can find every other endpoint’s encryption key without a private-key leak;

  • an organizational timestamping node that either syncs with Verae’s central timestamping server or is linked to it;

  • an admin-history cube that records configuration changes as previous state, new state, and diff;

  • an Iceberg write-once export that takes cubes out of any single party’s delete path (Chapter 9).

Each of those pieces can be drawn on a whiteboard in an audit interview. Each of them also has a failure mode that the organization’s procedures must name: lost keys, a mis-issued directory entry, a broker that drops messages, a replica that serves a wrong block (detected by hash), a timestamping link that is down, an archive job that did not run.

2.5. What the server solution is not

It is not a substitute for workforce training. It is not a substitute for a Business Associate Agreement analysis. It is not a substitute for access reviews. It is not, by itself, “the HIPAA control set” or “the SOC 2 system.” It is the technical substrate on which those controls can be implemented with less faith in honest administrators and more reliance on hashes, receipts, and keys the customer holds.

The following four chapters unpack the substrate: transit, rest, receipts, and the European evaluations of the Peergos storage layer.