Content Addressing

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 question.
• Is the payload encrypted? — that is the envelope and key management layer.
• Was access audited? — that is the 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 envelope contains the CID of its payload.
• Every ledger entry 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.