`sdmxlib-rest` is on 0.62.1 with a clean gate — 94 tests, `just check` green. Two things it still patches around are sdmxlib's to fix, and both are small. They are separable; split into two issues if that suits the tracker better. ## 1. The SDMX-JSON structure writer emits neither `urn` nor `links[rel="self"]` `MaintainableJson` (`formats/sdmx_json/_structure_dto.py:84`) has no `urn` field, and `_maint_fields` builds `links` from `uri_links(m)` alone — the `describedby` entry for `@uri` (#238) — so a written maintainable carries neither form of its own identity. The `rel="metadata"` back-links (#191) are appended by the writer on top of that, which is the only other `links` producer. SDMX-JSON requires one of the two so that cross-references *inside the same response* can resolve to their targets: a top-level `urn` property, or a `links` entry with `rel: "self"`. Emitting neither is not a defensible middle — a consumer either re-derives every URN from `(package, class, agency, id, version)` or its clients cannot follow a reference it just wrote. The .Stat Suite client (`@sis-cc/dotstatsuite-sdmxjs/getUrn.mjs`) reads **only** the `links[rel=self].urn` form with no fallback to the property, so a writer that picked one form would still need to be the right one; emitting both is what actually works. Everything needed is already here and already says so: - `Link` carries `rel` / `href` / `urn`, and the writer already constructs `Link(rel="metadata", …, urn=set_urn)` at `writer.py:159`. - `artefact_urn` is already imported in `writer.py:20`. - `URI_REL`'s own docstring (`_structure_dto.py:132`) states the rule this issue is asking to honour: the spec "reserves `self` for the artefact's own URN — which is the identity, not the pointer." So the change looks like a `urn` field on `MaintainableJson` and one more entry appended in `_maint_fields` beside `uri_links(m)`. Round-trip is safe in the direction that matters: `read_uri` already ignores every `rel` but `describedby`, so a `self` entry cannot be mistaken for a `@uri`. **What the consumer does today:** `sdmxlib_rest/responses/urn_injection.py` is a whole module — a post-serialise splice plus a hand-maintained table of 17 URN qualifiers mapping each SDMX-JSON collection key to its `(package, class)` pair — that walks the serialised body and splices both forms back in. That table is a copy of knowledge the model already holds, kept in step by hand, and it is the only reason the splice pipeline has a library-owned built-in at all (`splice.py`'s `inject_urns_in_place`, run last so it catches artefacts the consumer's own splices added). The splice is deliberately idempotent — it never overwrites an existing `urn` or a pre-existing `links[rel=self]` — so it can be left installed while this lands and deleted afterwards. No coordinated release needed. ## 2. A class-checked `get`, so #399's deviation stops reaching consumers #399 is right that the library has nothing wrong with it, and I am not asking to reopen that. Two things worth adding to it, then a request that does not depend on the checker at all. **The wait is open-ended.** #399 measured basedpyright 1.39.9 (pyright 1.1.411). I re-ran the `_REPRO` from `tests/unit/test_overload_any_ambiguity.py` against vanilla **pyright 1.1.414**, which is three patch releases newer than the one basedpyright ships on: | argument | spec | pyright 1.1.414 | basedpyright 1.39.9 | pyrefly 1.2.0 | | --- | --- | --- | --- | --- | | `Box[Any]` — contains `Any` | gradual | `LazyA` | `LazyA` | `Any` | | bare `Any` | gradual | `Unknown` | `Unknown` | `Any` | | `Box[B]` — unambiguous control | `LazyB` | `LazyB` | `LazyB` | `LazyB` | So it is inherited pyright behaviour, still present at latest, and not filed upstream by us. `probe_urn_any.py`'s "when basedpyright conforms" is therefore waiting on pyright, not on the fork. **The request:** an `expect=` form of `get` that does the class check itself. ```python def get[T](self, target: SdmxUrn[Any] | Ref[Any], /, *, expect: type[T], eager: bool = False) -> T | None ``` Returning the artefact when it is an instance of `expect` and `None` otherwise. It sidesteps #399 rather than fighting it: the argument at that overload is not the ambiguous `Box[Any]` shape, `T` comes from `expect`, and step 5 never applies — no change to `SdmxUrn.parse`, no reordering, and none of option 2's 52 + 27 findings. It also matches idioms already on the class: `get_all[T](artefact_type: type[T]) -> list[T]` already takes the class as the parameter that carries `T`, and `get`'s `eager: bool = False` already establishes the keyword. **Why it is a library concern and not a consumer's isinstance.** At `sdmxlib_rest/routes/metadata.py:313` and `:401`, both sites read: ```python sets = [ms for urn_str in set_urns if isinstance(ms := registry.get(sl.SdmxUrn.parse(urn_str)), sl.MetadataSet)] ``` with a four-line comment above each explaining the union. The runtime filter and the static narrowing there are **the same operation**: those URNs come from a store query, a row can legitimately point at something that is not a MetadataSet, and before the filter existed such a row reached the writer as one and failed there. So `expect=sl.MetadataSet` is not sugar over a cast — it is exactly the check the caller has to perform anyway, which is the argument for it living here. Any consumer resolving a URN parsed from a string at runtime writes this same line. ## Not asking for `catalog.data.inspect()` back, or a public accessor onto `LocalRegistry._data_store`. The 0.62 port moved `_shared_join_columns` to `DESCRIBE` on the DuckDB connection and that is the better source — it is the connection the route runs the JOIN on, so a store and a connection that disagreed about the schema can no longer build a query against the wrong one. Recorded here so nobody re-exposes it on our account. --- Consumer: `sdmxlib-rest` 0.2.0 on `sdmxlib>=0.62,<0.63` (resolved 0.62.1).