2 entries. All books.
Contents
- 24 Aug 19:27 — Moving the anthology into a record, and what the move found
- 24 Aug 20:02 — Consolidating the build, and suppressing my own CI while documenting how not to
Moving the anthology into a record, and what the move found
2026-08-24 19:27:46 · migration
The migration off data/*.yaml and into a Luria record (ADR-001). The
interesting part was not the transform, which is mechanical and lives in
src/scripts/migration/to_record.py. It was what became visible once each
claim had to be a document with a status and a resolvable citation.
The status field had never distinguished two records. All 119
recommendations were standard. MLRStatus defines experimental and
deprecated, and build_registry_from_yaml has branches that set them — but
both branches iterate paper.sota, and no experimental paper and no
superseded paper has a sota list. Three papers and two papers respectively;
zero recommendations produced by either branch. The code has been unreachable
on this corpus for as long as both have existed, and it fails in the quietest
possible way: by not running, while the schema keeps advertising three states.
That is DP-002.
The attic was pointing at papers that are not in the corpus.
2110.08058, 2002.05709 and 1911.05722 are named in attic.superseded_by
and attic.see_also and appear nowhere else in the data. Nothing resolved
them, so nothing could have said so. They are now written as ARXIV- codes
with the fact stated in the note bodies.
One retirement chain only makes sense once you can follow it. LIT-031
(Neural Networks are Surprisingly Modular) was atticked as superseded by
Clusterability in Neural Networks — which is LIT-041, and which was itself
later atticked with the reason “just doesn’t seem that interesting. Not sure
why Claude recommended this. Hallucination?” So the successor is Rejected.
Both facts were in the YAML; the relationship between them was not readable
from it. Somebody should decide what LIT-031 ought to point at now. It is
acknowledged rather than fixed, because guessing at it during a migration is
how a record acquires claims nobody made.
Two papers had no identifier and one paper had two entries. Imagen and
DALL-E 2 arrived with no arxiv_id; PaLM arrived twice under 2204.02311
with two different key_takeaways lists, only one of which carried sota.
The duplicate is invisible while papers are rows and impossible once each is
a file named for its own identity. The entries are merged and both takeaway
lists kept.
What I got wrong on the way
Deriving secondary tags. The first import scored secondary tags the same
way it scores the primary, and Adam came out tagged model-architecture —
because neural-networks is in its topic list and neural-networks maps
somewhere. Every generic string in the corpus does. The result is noise on
exactly the browsing pages the consolidation exists to make useful, so the
import now emits a primary and nothing else; the original strings survive
verbatim in keywords:.
Putting publication dates in date:. Reasonable-looking, and it made
luria lint report the Proposed notes as nine years overdue for a
decision, because date: is the filing date and staleness is measured from
it. A warning that is permanently wrong is the kind that gets a check
switched off. Filing date in date:, publication month in published:.
Using a real code as an example. The practice template and its index stub
illustrated citation syntax with LIT-041 — which is a real document, and a
Rejected one, so the templates were generating retired-citation findings
against themselves. The lint caught it immediately, which is roughly the
whole argument for having it.
Not done
The taxonomy consolidation is applied and enforced; the registry inversion
(ADR-006) is not. Until it is, data/ and record/ describe the same corpus
and neither updates the other. Practices are edited in the record;
research.yaml is frozen except for adding papers.
Some practice titles read poorly out of context — SOTA-001 is “Default choice for neural network training”, which was fine as a bullet under the Adam paper and is thin as a standalone claim. The import copied recommendation text verbatim rather than rewriting it, which is the right call for a migration and leaves a rewriting pass to do.
Consolidating the build, and suppressing my own CI while documenting how not to
2026-08-24 20:02:12 · migration
Two committing workflows, and the lint that stopped covering anything
(ADR-007). The record’s Docs workflow regenerates views and commits them,
then hands its lint job the SHA it produced — that handoff exists because a
lint running anywhere else would judge the pre-regeneration commit. It works,
and it only works if nothing else commits afterwards.
Build README did. The observable symptom was a pull request showing green
checks whose most recent commit had never been checked, plus a Docs run
parked at action_required with zero jobs, because the bot’s push had opened
a run that GitHub gates when the triggering actor is a bot.
The thing worth keeping: luria’s generate action had already solved its half by putting GitHub’s skip marker in its default commit message, so its own pushes open no runs. Every other committing job in this repository — the README builder, the SVG converter, the registry builder — carried no marker. The convention was present and unevenly applied, which is the failure mode that looks most like working.
What I got wrong. I wrote the commit message for that fix with the skip
marker spelled out literally, in a sentence explaining what the marker does.
GitHub read the explanation as an instruction and skipped every workflow on
the commit. docs.yml’s own header comment warns about exactly this and says
to name the marker in prose; I had read that comment, edited the file
directly above it, and then did the thing it warns about.
It is worth being precise about why it took a while to notice: the failure is not a red build, it is no build. The pull request went on displaying the previous commit’s green checks, which are the most recent checks that exist. Silence is indistinguishable from success unless you are checking which commit the green belongs to — and the first wait loop I wrote had the mirror of the same bug, exiting immediately on “no runs in progress” when the truth was “no runs at all”. Amending the message to describe the marker instead of spelling it produced three runs within seconds, which is the confirmation.
Retiring the registry pipeline (ADR-008). ADR-006 had proposed inverting
the registry build so the frontend could keep consuming a generated
registry.yaml, and left itself Proposed pending a look at the frontend
contract. Looking at it made the question dissolve: the chain existed to turn
structured data into something browsable, and docs/practices plus
luria site already are that. Inverting the projection would have kept three
artifacts alive to feed a fourth that duplicates a generated view.
So the decision that superseded it deletes rather than inverts, and ADR-006
is the record’s first Superseded decision — which is a small vindication of
the rule in DP-003, since the reasoning that was wrong is still readable next
to the reasoning that replaced it.
data/ stays frozen rather than deleted. Nothing reads it at build time, but
to_record.py needs it, and that script is the only thing that makes 238
generated documents auditable without reading all 238.
Not done
Settings → Pages → Source has to be switched to “GitHub Actions” by hand
before the site publishes; no file in the repository can set it. Until then
the Pages build job succeeds and the deploy job fails with “Pages is not
enabled”. On pull requests deploy is skipped by design, so this has not been
exercised yet — the first push to the default branch is where it either
works or says that.