ADR-005: Replace the derived MLR identifiers with sequential codes

Context

The old registry carried two identifiers per recommendation.

id looked like MLR-2014-Kingma001-0001: the year, an author key numbered by order of first appearance, and a counter within the paper. It was assigned by MLRIdentifierRegistry and persisted to a JSON side-file, which is the part that made it work at all — the author counter is allocated in corpus-traversal order, so inserting an earlier paper by a previously unseen author would renumber later ones if the side-file were ever lost.

topic_id looked like optimization/learning-rate-typically-1e-4-to: the topic, then a slug of the recommendation’s first five words, truncated mid-phrase. It is an identity derived from the text it identifies. Correcting a typo in a recommendation changes its topic_id. Nothing in the repository could have told you that had happened.

Both encode information — year, author, topic — that also lives in the record as fields. Two copies of a fact is the projection that drifts, and one of them was the primary key.

Decision

Sequential codes: SOTA-001, LIT-001. The number is assigned once, carries the order things entered the record, and means nothing else. The filename is the code and nothing else; the title lives in title:, where correcting it costs an edit rather than a rename plus every link that pointed at the old name.

Provenance that used to be encoded in the identifier is a field: source: names the paper’s note, date: comes from the arXiv posting month, tags carry the topic.

Alternatives considered

• Keep MLR ids as an alias. Luria supports aka: aliases for exactly this, and the case for it is external links. There are none: the ids appear in registry.yaml and REGISTRY.md, both of which this project generates, and nowhere else that is reachable. An alias nobody follows is a field to keep in step.
• Use the arXiv id as the practice identifier. It identifies the paper, not the recommendation, and papers produce up to four. It is right for LIT, which is why arxiv: is a required field there — but as a field, not as the code, so a paper with no id can still be filed and flagged.
• Content-address the recommendation text. The topic_id idea taken seriously, and it has the same defect at any hash length: the identity of a claim changes when the wording is improved.

Consequences

data/registry.yaml still contains MLR ids and still validates; nothing

about this changes it. When ADR-006 inverts the build, the generated file can emit either form, and dropping them is a decision to make then, with the frontend in front of you.

The mapping from old id to new code is not recorded anywhere, deliberately — it is recoverable from the migration script and the registry order, and a committed mapping table would be a third copy of the same fact.