wellcomecollection · kenoir · Sep 15, 2026 · Sep 15, 2026 · Sep 15, 2026
@@ -349,8 +349,8 @@ If it is useful for other Wellcome processes or workflows to know about sub-pack
 
 The earlier version of this RFC sketched a "Wellcome identity service" — given a string identity, return all known current and previous identifiers that match it — and asked what would distinguish it from the catalogue API's `identifiers` query. That service now exists: the [Identifiers API of RFC 089](../089-identifiers-api/README.md), a read-only projection over the catalogue ID Registry (the store the RFC 083 ID Minter writes to). Its contract supersedes the sketch:
 
-- `GET /v1/identifiers/{canonicalId}` returns the full set of source identifiers for a canonical id;
-- `GET /v1/identifiers/by-source/{sourceSystem}/{value}?include=siblings` resolves a source identifier to its canonical id and labelled siblings (`sierra-system-number`, `calm-ref-no`, `folio-instance`, ...).
+- `GET /identifiers/v1/{canonicalId}` returns the full set of source identifiers for a canonical id;
+- `GET /identifiers/v1/by-source/{sourceSystem}/{value}?include=siblings` resolves a source identifier to its canonical id and labelled siblings (`sierra-system-number`, `calm-ref-no`, `folio-instance`, ...).
 
 The questions the sketch left open are now answered. Lookups are **qualified** by source system rather than the sketched bare `?q=` — a bare-value lookup was considered and rejected, because the registry could enumerate ambiguous matches but not rank them (every digitised b number sits under both `sierra-system-number` and `mets` with different canonical ids, and which is public is merger knowledge the registry does not hold), so the DDS keeps a thin precedence rule and queries qualified. Obsolescence is expressed as **`isAlias`** on each row (the original, earliest-created identifier is `isAlias: false`; inherited predecessors are `true`) rather than the `obsolete` flag this RFC floated. And the difference from the catalogue API is that the registry answers from the minting record, independent of whether a work has flowed through the pipeline and become visible — but by the same token it holds only what the Minter minted, not the catalogue API's full merged `identifiers` view (ISBNs and the like), and it **cannot hold the result of redirection from merge** (see [The redirect contract](#the-redirect-contract)).
 

@@ -11,7 +11,7 @@ Sierra/CALM → FOLIO/Axiell migration. It sets out the contract, the AWS archit
 authentication and cost model, the caching strategy, and what a working prototype has already
 established.
 
-**Last modified:** 2026-08-05T15:00:00+00:00
+**Last modified:** 2026-09-15T10:29:00+00:00
 
 **Related RFCs:**
 
@@ -125,14 +125,16 @@ operations:
 
 ## API Contract
 
-Two endpoints. The machine-readable contract is the OpenAPI spec carried alongside this RFC (see
-[OpenAPI specification](#openapi-specification)); this is the summary.
+Two endpoints. The machine-readable contract is the OpenAPI spec in catalogue-api (see
+[OpenAPI specification](#openapi-specification)); this is the summary. The paths sit under
+`/identifiers/` because `api.wellcomecollection.org` routes each service by its first path segment,
+so the public form is `https://api.wellcomecollection.org/identifiers/v1/...`.
 
 | Endpoint | Returns |
 |---|---|
-| `GET /v1/identifiers/{canonicalId}` | The full `IdentifierSet` (always; there is no aliases toggle), ordered by `createdAt` so the original is first. |
-| `GET /v1/identifiers/by-source/{sourceSystem}/{value}?type=Work` | A bare `{ "canonicalId": "..." }` (`CanonicalIdRef`). |
-| `GET /v1/identifiers/by-source/{sourceSystem}/{value}?type=Work&include=siblings` | The same full `IdentifierSet`. |
+| `GET /identifiers/v1/{canonicalId}` | The full `IdentifierSet` (always; there is no aliases toggle), ordered by `createdAt` so the original is first. |
+| `GET /identifiers/v1/by-source/{sourceSystem}/{value}?type=Work` | A bare `{ "canonicalId": "..." }` (`CanonicalIdRef`). |
+| `GET /identifiers/v1/by-source/{sourceSystem}/{value}?type=Work&include=siblings` | The same full `IdentifierSet`. |
 
 The element shape (`SourceIdentifier`) is identical across both endpoints, so one schema and one
 parser serve every response:

@@ -74,10 +74,10 @@ _This is generated from the RFCs in this directory using `.scripts/create_table_
 
 | RFC ID | Summary | Next Line | Last Modified |
 |--------|---------|-----------|---------------|
+| [089-identifiers-api](089-identifiers-api/README.md) | RFC 089: Identifiers API | This RFC proposes a small, read-only **Identifiers API** that resolves a **canonical** catalogue identifier to its **source** identifier(s) and back, served from the catalogue ID Registry (the same store the ID Minter writes to, per [RFC 083](../083-stable_identifiers/README.md)). It provides that translation in one place, between the canonical ids the public surface uses and the source ids (Sierra numbers, FOLIO UUIDs, CALM/Axiell refs) that the underlying systems require across the Sierra/CALM → FOLIO/Axiell migration. It sets out the contract, the AWS architecture, the authentication and cost model, the caching strategy, and what a working prototype has already established. | 15 Sep 2026 |
 | [091-digitisation-ingest-identifiers](091-digitisation-ingest-identifiers/README.md) | RFC 091: Preservation identifiers across the LMS migration | Wellcome Collection is migrating its library management system from Sierra to Folio, and its archive management system from CALM to Axiell Collections. The Sierra b-number is embedded in storage locations, METS records, IIIF manifest URIs, and the join key that merges digitised content onto the public catalogue work. This RFC names that identifier role the **preservation identifier**, records the decision that preservation identifiers remain the canonical identifiers for digital objects (nothing is minted at ingest, and IIIF Manifest URIs do not move to the catalogue Work id), and sets out cross-migration and post-migration ingest paths covering both digitised and born-digital content. For items ingested after the migration the proposed preservation identifier is the Folio instance HRID, e.g. `in00012345`. | 18 Aug 2026 |
 | [092-digitised-archive-links](092-digitised-archive-links/README.md) | RFC 092: Keeping digitised archive material connected after Sierra | Digitised archive material on wellcomecollection.org is connected to its archive description through the CALM-synced Sierra bib, and those bibs are deliberately not migrated to FOLIO. This RFC records how the connection works today, shows that the catalogue pipeline can maintain it with no Sierra or FOLIO record existing provided the Axiell Collections record cites the Sierra b number, and quantifies the gap (roughly 93% of digitised archive records carry no b number in Axiell). The proposed fix is to import the missing b numbers into Axiell Collections, matched on each record's public reference and verified through the CALM RecordID carried in the migration. It is the archive-side companion to RFC 091, which covers the library-side (FOLIO-target) half of post-migration digitisation merging. | 18 Aug 2026 |
 | [085-IIIF-Identities-and-Migration](085-IIIF-Identities-and-Migration/README.md) | RFC 085: Identifiers of and within IIIF resources after the migration | To record the agreed approach to IIIF resource identity across the LMS migration: preservation identifiers remain the canonical URIs for IIIF Manifests and Collections, for old and new content alike, with Work IDs acting only as redirect sources. The RFC retains the analysis that led to this decision — chiefly the behaviour of Canvas IDs and annotation targets — and sets out the consequences for the DDS: the redirect contract, the constraints on the form of new preservation identifiers, sub-package identity, and the persistence of Canvas identity. | 07 Aug 2026 |
-| [089-identifiers-api](089-identifiers-api/README.md) | RFC 089: Identifiers API | This RFC proposes a small, read-only **Identifiers API** that resolves a **canonical** catalogue identifier to its **source** identifier(s) and back, served from the catalogue ID Registry (the same store the ID Minter writes to, per [RFC 083](../083-stable_identifiers/README.md)). It provides that translation in one place, between the canonical ids the public surface uses and the source ids (Sierra numbers, FOLIO UUIDs, CALM/Axiell refs) that the underlying systems require across the Sierra/CALM → FOLIO/Axiell migration. It sets out the contract, the AWS architecture, the authentication and cost model, the caching strategy, and what a working prototype has already established. | 05 Aug 2026 |
 | [090-axiell-folio-sync](090-axiell-folio-sync/README.md) | RFC 090: CMS to LMS Sync | This RFC proposes an automated pipeline to synchronize data from **Axiell Collections (AxC)**, the new Content Management System (CMS), into **FOLIO**, the new Library Management System (LMS). The records from Axiell Collections need to exist in FOLIO so they can be requested and circulated in the LMS. It is designed for **idempotency** (safe to replay without duplication), **auditability** (every create / update / suppress is recorded), and **graceful error isolation** (one bad record never halts the batch). | 30 Jun 2026 |
 | [088-folio-identity-requesting-migration](088-folio-identity-requesting-migration/README.md) | RFC 088: Migrating identity, requesting and items APIs from Sierra to FOLIO | This RFC describes how we move the identity, requesting and item-availability APIs that power `wellcomecollection.org` from our current Library Management System (LMS), **Sierra**, to its replacement, **FOLIO**. It sets out the proposed architecture (a parallel, FOLIO-backed **v2** identity API fronted by Auth0), the embedded API contract, the migration plan (a per-request website toggle plus lazy patron migration, culminating in a single coordinated cutover), and the questions still open before cutover. | 26 Jun 2026 |
 | [087-kiosk-mode](087-kiosk-mode/README.md) | RFC 087: wellcomecollection.org in kiosk mode | This RFC serves to outline how we propose to offer in-venue experiences using our current website, while optimising it for a different experience than usual. | 13 May 2026 |