# Record
**Author:** @cameron.stream (`did:plc:gfrmhdmjvxn2sjedzboeudef`)

## `knowledge-atproto-records-and-provenance`
**Collection:** `site.standard.document`
**AT URI:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.document/knowledge-atproto-records-and-provenance`

**Title:** ATProto Records and Provenance
**Published:** Mon, 20 Jul 2026 22:19:49 GMT
**Updated:** Mon, 20 Jul 2026 21:02:00 GMT
**Description:** A practical guide to finding an ATProto record, identifying its publisher, and preserving the exact version you saw.
**Publication:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.publication/3mr4py6clps2f`
**Path:** /atproto-records-and-provenance
**Tags:** knowledge, concept, atproto, protocols, provenance, identity, strong-references

**Content:**
````json
{
  "text": "In [AT Protocol](https://atproto.com/), a **record** is a schema-defined data object published in a repository owned by an account. ATProto records include posts, profiles, bookmarks, annotations, and other application data.\n\nATProto gives each record several identifiers because a useful reference may need to answer three different questions:\n\n1. Where is the record?\n2. Who published it?\n3. Which exact version was observed?\n\nThis page is part of the [AT Protocol](https://cameron.stream/knowledge/atproto) section of this wiki. It explains how AT URIs, DIDs, CIDs, repositories, and Lexicons answer those questions, and which identifiers an ATProto application should preserve when it links to a record.\n\n## One record, two kinds of identity\n\nA public ATProto record has an address called an **AT URI**. It looks like this:\n\n`at://did:plc:example/app.example.bookmark/3abc`\n\nYou do not need to memorize the syntax. It has three useful parts:\n\n- `did:plc:example` identifies the account that owns the record;\n- `app.example.bookmark` identifies the type of record;\n- `3abc` identifies this particular record within that type.\n\nThe first part is a **DID**, or decentralized identifier. A DID is the stable identity behind an ATProto account. Handles can change, and an account can move to another Personal Data Server, but the DID remains the record's authority.\n\nThe complete AT URI is the record's logical address. An author can edit the record without changing that address.\n\nThat is where the second identifier becomes useful. A **CID**, or content identifier, is a fingerprint of the record's exact encoded contents. Change the contents and the CID changes.\n\nThe distinction is similar to a document URL and a checksum:\n\n- the AT URI tells you which document you mean;\n- the CID tells you which version of that document you saw.\n\n## What happens after an edit\n\nImagine a bookmark record with this description:\n\n> A clear introduction to distributed social networking.\n\nIts address might remain:\n\n`at://did:plc:example/app.example.bookmark/3abc`\n\nIf the author later changes the description, the AT URI stays the same. The CID changes because the record's contents changed.\n\nThis gives applications a choice. They can follow the AT URI to whatever the record says now, or they can preserve the CID when the exact earlier version matters.\n\nATProto's standard **strong reference** stores both:\n\n```json\n{\n  \"uri\": \"at://did:plc:example/app.example.bookmark/3abc\",\n  \"cid\": \"bafy...\"\n}\n```\n\nThe URI identifies the record. The CID records the version that was observed when the reference was created.\n\n## Where the record lives\n\nEach ATProto account has a repository containing its public records. The account's DID document tells the network which Personal Data Server currently hosts that repository.\n\nThe [repository](https://atproto.com/specs/repository) is a verifiable key/value store. Record addresses are the keys; CIDs point to the current values. The repository publishes signed commits that anchor its current state. A proof through the repository's Merkle tree can connect a record path and CID to that signed state.\n\nThis is what makes a copied record inspectable. A consumer does not have to trust the server that handed it the bytes. It can verify the content against the CID and verify the repository path against the account's signed state.\n\n## How the record gets its shape\n\nA **Lexicon** is ATProto's schema format. It describes which fields a record may contain and what types those fields use.\n\nFor example, a bookmark Lexicon might require a URL and creation time while allowing an optional description. The record's `$type` field names the Lexicon that describes it.\n\n[Lexicons](https://atproto.com/specs/lexicon) make records understandable across applications. They establish shape, not truth. A valid record can still contain a false claim, a broken URL, or a judgment another application rejects.\n\n## Which reference should you keep?\n\nUse an **AT URI by itself** when you want the current version of a record. A profile link or a live collection entry often works this way.\n\nUse an **AT URI and CID together** when the exact version matters. Common examples include:\n\n- a reply to a particular post;\n- an annotation quoting a passage;\n- a moderation or approval decision;\n- a research note that should remain reproducible;\n- an audit log explaining what a system acted on.\n\nUse a **CID by itself** only when you care about exact bytes independently of their publisher and repository address. You will still need another way to find those bytes and explain what they represent.\n\n## What provenance does not prove\n\nThese identifiers can show who published a record, where it lived, and which version was referenced. They cannot prove that its claims are correct or that another community has accepted it.\n\nThose are separate decisions. A forum may publish an [ATProto admission wrapper](https://cameron.stream/knowledge/atproto-admission-wrappers) saying that a member's post belongs in one of its categories. A reviewer may approve one CID but not later edits at the same URI, which creates the problem described in [Approving Mutable ATProto Records](https://cameron.stream/knowledge/atproto-approving-mutable-records).\n\nThe practical rule is simple: preserve the address when identity matters, preserve the fingerprint when version matters, and preserve both when another decision depends on what was actually seen.\n\n## Sources\n\n- [AT Protocol repository specification](https://atproto.com/specs/repository)\n- [AT Protocol data model](https://atproto.com/specs/data-model)\n- [AT Protocol Lexicon specification](https://atproto.com/specs/lexicon)\n- [com.atproto.repo.strongRef](https://github.com/bluesky-social/atproto/blob/main/lexicons/com/atproto/repo/strongRef.json)",
  "$type": "site.standard.content.markdown",
  "version": "1.0"
}
````

---
*Fetched from https://enoki.us-east.host.bsky.network via `com.atproto.repo.getRecord`*