---
title: Content Addressing | Docs | Lattix
description: How Lattix identifies data objects, by cryptographic hash of content rather than by location.
source: "https://lattix.io/docs/concepts/content-addressing/"
content-type: text/markdown
---

# Content Addressing | Docs | Lattix

Core Concepts

# Content Addressing

How Lattix identifies data objects, by cryptographic hash of content rather than by location.

Lattix identifies every protected data object by a content identifier (CID) derived from the object's content. Two bytes-identical objects get the same identifier. Any change to the payload (even a single bit) produces a different identifier. This is what is meant by *content addressing*: the identity of the data is what it contains, not where it is stored.

## Why addressing by content matters

**Integrity is intrinsic.** Because the identifier is a cryptographic hash of the content, mere possession of the identifier and the content is enough to verify the content has not been modified. The integrity check is not a separate system — it is the identifier itself.

**Deduplication is automatic.** If the same object is wrapped, shared, or uploaded twice, both instances share the same identifier. Storage, audit, and lineage can reference a single object identity across every location it exists.

**Lineage is verifiable.** When an object is produced from another object (a re-encrypted copy, a redaction, a derived dataset), the lineage graph records the relationship between the source CID and the derived CID. Verifying provenance becomes a traversal of the graph.

**Location is decoupled from identity.** A data object referenced by CID can be retrieved from whatever storage layer currently holds it — on-premises object storage, a cloud bucket, a peer in a coalition network. The identity does not change when the object moves.

## How it fits into Lattix

The content addressing layer sits under the data-handling products. When Passport wraps a file, when a Data Room imports a document, or when a Mesh Node processes a data object, the payload's CID is computed as part of the envelope manifest. Downstream:

- The **ledger** records the CID, so "who accessed this object" is a query against a stable identifier.
- **Policies** can reference CIDs directly, supporting object-level deny policies ("never release this specific record").
- **Assertions** are signed against the CID, so a claim about an object ("this document was reviewed and approved for release") cannot be transplanted to a modified version.

## Version graphs

Objects evolve. A quarterly report is revised; a dataset is re-released with corrections; a design document moves through three approved revisions. Lattix tracks these evolutions as a version graph. Each new version has its own CID, and the parent-child relationship to its predecessor is recorded.

A consumer holding the CID of a past version can discover the current version (if authorized by policy). An auditor investigating a past decision can retrieve exactly the version that was in force at the time, bit-for-bit.

## What CIDs do not solve

Content addressing is an identity layer. It does not, on its own, answer questions like:

- *Who should be allowed to read this?*, that is a [policy](https://lattix.io/docs/concepts/policies-and-abac/) question.
- *Is the payload encrypted?*, that is the [envelope](https://lattix.io/docs/concepts/trusted-data-format/) and [key management](https://lattix.io/docs/concepts/hierarchical-key-model/) layer.
- *Was access audited?*, that is the [ledger](https://lattix.io/docs/concepts/immutable-ledger/).

But because every protected object has a stable CID, all of those layers can refer to the same object unambiguously, across systems that otherwise have no shared state.

## Relationship to other concepts

- Every [Trusted Data Format](https://lattix.io/docs/concepts/trusted-data-format/) envelope contains the CID of its payload.
- Every [ledger entry](https://lattix.io/docs/concepts/immutable-ledger/) references the CID of the object the decision was about.
- The **lineage graph** is exposed in the Mesh Dashboard under object history, see [Products → Lattix Passport](https://lattix.io/docs/products/lattix-passport/).

[Immutable Ledger Tamper-evident audit for every policy decision and key release in the Lattix platform.](https://lattix.io/docs/concepts/immutable-ledger/) [Cryptographic Agility How Lattix helps administrators manage cryptographic transition for protected data over time: tenant profiles, key lifecycles, observable migration events, and rewrap campaigns.](https://lattix.io/docs/concepts/cryptographic-agility/)