Platform Overview

Lattix coordinates five layers so that every piece of protected data carries its own security and every access to it produces tamper-evident evidence. This page walks through those layers in the order data and decisions actually move through the system.

The five layers

Identity establishes who (or what) is making a request. Lattix accepts OIDC and SAML identity providers. Human users, service accounts, and autonomous agents all become principals with attributes — role, clearance level, group memberships, device posture — that policy can evaluate.

Policy defines the conditions under which a specific data object can be accessed. Policies are written as attribute-based access control (ABAC) rules and evaluated by the Policy Decision Plane. A policy can reference any combination of principal attributes, data classification, time, location, and contextual signals.

Encryption wraps every data object in a cryptographic envelope. Each object gets its own data encryption key (DEK), which is itself wrapped under a key encryption key (KEK) held by the tenant's configured key management backend. The envelope is independent of where the data lives — it travels with the data.

Enforcement is where a request to unwrap an object is evaluated. The Policy Enforcement Point (PEP) consults the Policy Decision Plane, requires a valid signed decision, and only then releases the DEK. Without a positive decision, the data remains ciphertext.

Audit records every decision on an immutable ledger. Both positive and negative decisions are anchored, with the data object identity, the requester, the policy evaluated, and the outcome. This provides bidirectional evidence — the presence of a record proves access, the absence proves it did not occur.

How a typical request flows

1. A producer creates or imports a data object. The object is classified (automatically or with author input), assigned a policy, and wrapped in a Trusted Data Format envelope. The encrypted payload plus manifest can now travel freely.

2. A consumer requests the object. Their identity provider issues an authenticated token; Lattix resolves the token into a set of attributes.

3. The Policy Decision Plane evaluates the object's policy against the consumer's attributes and the current context. It produces a cryptographically signed decision.

4. The Policy Enforcement Point verifies the signed decision and, if it grants access, requests the wrapped key from the Key Access Service.

5. The wrapped DEK is released, the consumer decrypts the object locally, and an audit record is written to the immutable ledger capturing the full evaluation.

If any step fails — invalid identity, policy denial, revoked key, expired decision — the object remains encrypted and a denied-access record is written to the ledger.

What makes this different

Traditional security architectures protect the container around the data: the server, the network segment, the application. When the data leaves that container, its protection ends. Lattix inverts the model. Because the envelope travels with the data, the same protection applies in your cloud, in a partner's cloud, on a laptop, on a USB drive, or in email — and revoking access after the fact is still effective because subsequent decryption attempts will fail.

The rest of this documentation

The remaining sections take each layer in turn:

• Core Concepts — the primitives: Trusted Data Format, ABAC, the hierarchical key model, the mesh fabric, the immutable ledger, content addressing, and post-quantum encryption.
• Products — the products that expose these primitives to users: Lattix Passport, Data Rooms, the Zero Trust Fabric, the Mesh Node, the Immutable Ledger, connectors, and the Policy Engine.
• Configuration — the administrative controls a tenant administrator configures.
• Best Practices — recommendations for rolling this out successfully.