Triunnia Labs

Every Entity, Encrypted and Versioned

The Entity Api stores any serializable object model as a named, versioned record. Every entity is encrypted with a key the server never holds. Every update automatically preserves the prior version. A breach of the database yields ciphertext and version numbers — nothing readable, nothing reversible.

The Server Cannot Read What It Stores

Encryption Keys Stay With the Client

A Key the Server Never Retains

Each entity is encrypted with a key the client supplies on every request. The server uses the key to decrypt, perform the operation, and store only the resulting ciphertext. The key is never persisted — not to disk, not to memory between requests.

Breach-Resistant by Construction

Full server compromise delivers ciphertext for every entity the server stores. Reconstructing the plaintext requires the per-entity key from the client. An attacker who exfiltrates the entire database has exfiltrated nothing usable. The encryption guarantee does not depend on the server remaining uncompromised.

Every Change, Preserved

Version History Without Extra Infrastructure

Versioning Built Into Every Write

Each update to an entity increments its version counter and archives the previous version automatically. No triggers, temporal tables, or application-layer diff logic are required. The Entity Api handles the archival at the storage layer — the developer calls Update and the history is kept.

Full History on Demand

GetHistory returns every prior version of an entity in chronological order. Audit trails, compliance records, and point-in-time recovery are built-in outcomes of normal write operations. The current version and its entire lineage are accessible through a single client interface.

Store Anything Serializable

The API Is Agnostic to Data Shape

Type Names Are Yours to Define

The Entity Api stores any MessagePack-serializable object model. Type names are consumer-defined strings — the API enforces no schema, creates no columns, and performs no migrations. User profiles, document versions, application settings, workflow state, and audit records all store through the same interface.

Generic Overloads Handle Serialization

The client library provides generic overloads that accept a typed object and return a typed object. MessagePack serialization and deserialization are handled internally. The developer works with strongly typed models and the Entity Api handles the binary representation.

Archive, Recover, or Purge

The Lifecycle Is Yours to Control

Soft Delete Preserves the Record

SoftDelete moves an entity to a separate archive table. Archived entities are removed from active queries but remain accessible via GetArchived. Compliance requirements that prohibit destruction before a retention period are handled by archiving rather than purging.

Purge Removes Everything

Purge removes the entity, its current version, and its entire history in a single operation. No orphaned records remain. When the right to erasure applies, Purge satisfies it completely.

Connected by Design

Entity Is Built for the Full Arch Stack

Keys Api

Encryption keys for entities are best managed in the Keys Api. The Keys Api stores per-entity or per-user encryption keys under the same sovereignty guarantees as the entity data itself. A client derives its encryption key from the Keys Api and supplies it to the Entity Api on each request.

Your Application

Your microservice stores and retrieves objects through the IEntityApiClient interface. Encryption is enforced on every write without additional calls. A full version history accumulates as a side effect of normal updates. What would otherwise be separate audit, encryption, and archival systems is the default behavior of a single dependency.