> For the complete documentation index, see [llms.txt](https://docs.wellcomecollection.org/storage-service/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wellcomecollection.org/storage-service/reference-design-decisison/identifiers.md).

# How identifiers work in the storage service

Bags in the storage service have a three-part identifier:

* **Space:** the broad category of a bag. Examples: `digitised`, `born-digital`.
* **External identifier:** the identifier of a bag within a space. This is typically an identifier from another system, which matches this bag to that record. Examples: `b31497652`, `PP/CRI/A/2`.
* **Version:** an auto-incrementing numeric value. This tracks distinct versions of a (space, external identifier) pair. Examples: `v1`, `v2`, `v3`.

The space and external identifier are supplied by the user; the version is automatically generated by the storage service.

These three parts can be combined into a single string, which uniquely identifies a bag; for example `digitised/b31497652/v2`. This identifier is also the path to [the root of the bag inside our storage buckets](/storage-service/reference-design-decisison/file-layout.md).

Why did we choose this approach?

* We want identifiers that are human-readable and understandable. (As opposed to, say, [UUIDs](https://en.wikipedia.org/wiki/Universally_unique_identifier).)
* We match bags to records in systems outside the storage service (for example, the library catalogue). This approach allows us to use the same identifier as the external system, rather than [inventing another type of identifier](https://xkcd.com/927/).
* This structure allows us to group related content by space within the underlying storage, in a way that is human-readable:

  ```
  digitised/
    ├── record1/
    │     ├── v1/
    │     │    ├── bagit.txt
    │     │    ├── bag-info.txt
    │     │    └── data/
    │     │          ├── record1_0001.jp2
    │     │          └── ...
    │     └── v2/
    │          └── ...
    │
    └── record2/
          └── v1/
               └── ...
  ```

  The human-readable storage layout means our files are not tied to the specific software implementation of the storage service.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.wellcomecollection.org/storage-service/reference-design-decisison/identifiers.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.