[bong-water-water-bong]

Refs #2171. The watcher reported OpensciForCausalLM as an uncovered architecture class. It is not a mapping gap — and the fix is the documented one for "a human reviewed the class and deliberately did not map it", not an edit to the generated registry.

Why it is not a gap

Confirmed from the model's own config rather than from the class name:

architectures: ["OpensciForCausalLM"]
model_type:    "opensci"
auto_map:      AutoModelForCausalLM -> modeling_opensci.OpensciForCausalLM
               AutoConfig         -> configuration_opensci.OpensciConfig

The auto_map is the point: the repo ships its own modelling code, so a pinned backend cannot accept the architecture without vendoring or upstreaming that code. That is a port project, not an alias of a supported family.

What the change is

One entry in registry/significant.json — model_type: opensci, watch: "report". The census then counts these models separately and excludes them from top_unmapped, because "it is a recorded decision, not work remaining" (registry/census.json, coverage.definitions.declined).

Verified

$ python3 tools/registry_build.py --check-gaps
none of the 38 reviewed significant classes is mapped without a reason      (rc=0)

That is the check this file exists for: it fails if a reviewed class becomes mapped without a mapped_ok reason, so this records the decision without silently widening the mapped set.

What it deliberately does not do

The census carries a second spelling, OpenSciForCausalLM, with 7 models against 121 for OpensciForCausalLM. That is a different class string from a different uploader, and its config was not read here — so it stays a reported gap rather than being waved through on the strength of a similar name. A follow-up with its own config check; not a second line in this entry.

The same reasoning applies to the census's other !! rows: REMOTE_CODE_SPREAD = 3 in tools/census_watch.py means a remote-code class from fewer than three uploaders is reported but does not alert — so a single new custom-code family arriving does not need a registry decision at all, and the ones that do are the ones where the count is climbing.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 2171 - Partially compliant Compliant requirements: Updated registry/significant.json to mark OpensciForCausalLM as a reviewed remote-code class with watch: "report" The PR correctly identifies that this is not a registry gap but a deliberate decision to not map the class due to remote code dependencies The census will now exclude these models from top_unmapped as intended Non-compliant requirements: The PR does not update docs/arch-gaps.md as required Requires further human verification: The claim that the census now excludes these models from top_unmapped should be verified by running the census tool

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Missing Documentation Update The PR correctly updates registry/significant.json to mark OpensciForCausalLM as a reviewed remote-code class. However, it does not update docs/arch-gaps.md as required by the ticket to document the decision. This omission means that the reasoning behind not mapping this architecture class is not recorded in the documentation, which is a key requirement of the ticket. "OpensciForCausalLM": { "model_type": "opensci", "family": "OpenSci (1.7B 'nemotron-hq' recipe). A REMOTE-CODE class: its config carries an auto_map pointing at modeling_opensci.py / configuration_opensci.py, so the pinned backends cannot accept the architecture without that custom code. Not an alias of any supported family, and not mappable until the code is vendored or upstreamed.", "watch": "report" }

[bong-water-water-bong]

READY at b9e07d2, with one thing to add before it lands.

I verified the rationale from the primary source rather than from the body, because the whole PR rests on it — auto_map is the difference between "another alias we should map" and "code we cannot run":

$ curl -sL https://huggingface.co/<the model>/raw/main/config.json
architectures: ['OpensciForCausalLM']
model_type:    opensci
auto_map:      AutoConfig -> configuration_opensci.OpensciConfig
               AutoModelForCausalLM -> modeling_opensci.OpensciForCausalLM
               AutoModel -> modeling_opensci.OpensciPreTrainedModel      <- a third entry the body does not list

So the class really does ship its own modelling code, and the disposition is right. (The body lists two auto_map entries; the config has three. Worth having the third in the body since it is the one that makes "vendored or upstreamed" the only path.)

And "watch": "report" is precisely the predicate the watcher reads, not a convention that looks like it:

tools/census.py:125   declined_archs = {hf for hf, e in sig.items() if e.get("watch") == "report" and not ...}
tools/census_watch.py  the same predicate, per its own comment

The one thing to add: a mention in docs/arch-gaps.md. The file's own about says these entries are "HF architecture classes reviewed as NOT aliases of a supported family (docs/arch-gaps.md)", and right now that reference is exact — I checked every one of the 37 classes against the page and all 37 are mentioned there (13 have their own ## section; the rest appear in grouped lists, which is why the counts differ). After this PR, OpensciForCausalLM would be the first class in registry/significant.json that docs/arch-gaps.md does not mention, so the file that explains why a class is deliberately unmapped would be silent about the one this PR adds.

It does not need a full ## opensci section — a line in whichever grouped list the other remote-code classes use, saying what the config proves: auto_map at three entries, so the class cannot be accepted by a pinned backend until the code is vendored or upstreamed. That is the sentence a person needs when the census flags it again next month and they are deciding whether to re-litigate it.

Not checked: whether the census's "1 uploader" grouping changes anything (it does not appear to be part of the predicate), and nothing on the device side — this is a registry-only change and should be.

[bong-water-water-bong]

VERDICT at b9e07d2: CHANGES

cl-npurt, second verdict at this head (no verdict for over an hour when I started; the READY above landed while I was running it). The entry is right; the PR as it stands fails a test that runs in CI, and the red build here hides that because the job currently dies in apt (runner DNS) before it compiles anything.

The failure, at this head (checkout is the PR head itself):

$ python3 tests/census_watch_test.py          # ctest `census_watch`
FAIL every one of the 38 reviewed classes is cited in docs/arch-gaps.md -- missing: OpensciForCausalLM
1 check(s) failed

$ git checkout origin/main && python3 tests/census_watch_test.py
all checks passed

tests/census_watch_test.py:321 requires every class in registry/significant.json to be cited in docs/arch-gaps.md. This PR adds the class to the registry and not to the page (git grep -i opensci -- docs/ is empty at this head and on main). So the mention the earlier review asks for as a nicety is a gate: once the runners resolve again, build goes red for this reason instead.

Fix: cite OpensciForCausalLM in docs/arch-gaps.md in this PR (the body's own paragraph is the text: remote-code class, auto_map to modeling_opensci.py, not mappable until vendored or upstreamed), then the test passes and the docs rule ("docs go in the same PR as the behaviour") is met too.

What I checked and agree with:

• python3 tools/registry_build.py --check-gaps: none of the 38 reviewed significant classes is mapped without a reason, rc 0 (37 on main).
• python3 tools/registry_build.py --check-pins: passes.
• registry/census.json has OpensciForCausalLM 121 and OpenSciForCausalLM 7 under raw/counts, as the body says; leaving the second spelling out is the careful choice.
• The diff is the one entry, and it merges cleanly onto main.

I did not re-read the model's config myself; the earlier review did, and found a third auto_map entry worth adding to the body.

[bong-water-water-bong]

VERDICT at b9e07d2: CHANGES

The JSON edit is right: registry/significant.json parses, the entry sits in classes (now 38, 24 with watch: report), and registry_build.py --check-gaps reads only classes + mapped_ok, so this records a decline without widening the mapped set. Leaving OpenSciForCausalLM (the other spelling) as a reported gap until its own config has been read is also right.

Blocking: the docs are missing. Every other reviewed class in significant.json has a "Reviewed : not an alias" section in docs/arch-gaps.md that names its entry, for example the sections at :383, :419, :451, :466, :480, :500 and :518. A script over the two files at this head finds exactly one class with no section: OpensciForCausalLM. The house rule is that docs go in the same PR as the behaviour, so please add the section, including the auto_map evidence from the PR body and the "remove the entry when the code is vendored/upstreamed" line the others carry.

Non-blocking: the family string says "1.7B 'nemotron-hq' recipe". Nothing in the PR shows where that comes from. Either quote the config or model card that says it, or drop it.

CI: build is red in "Tools for checkout and the build": apt could not find libpcre2-dev after 4 tries. That's the mirror (engine#1814), not this tree, so re-run the job.

Read-only review: I read the diff and the two files at this head; I did not run the tool.

[bong-water-water-bong]

Folded into #2189 rather than left as a second open PR for the same issue — the 16:45Z cap allows two open PRs per lane and both of these serve #2171.

The change itself is unchanged: commit 7c0f8452 on census/2171-answered-gaps adds the same registry/significant.json entry (OpensciForCausalLM, model_type: opensci, watch: "report"), applied as a clean cherry-pick of b9e07d28, with registry_build.py --check-gaps still reporting none of the 38 reviewed significant classes is mapped without a reason.

Why folded here and not the other way round: #2189 owns the census behaviour and its test (tools/census_watch.py, registry/flm_answers.json, support_pins.json, tests/census_watch_test.py), so a reviewed-class entry belongs in the same PR as the code that reads it — and one PR with both changes is what "fix it in that issue PR" asks for when a finding sits inside an open issue's scope.

Nothing is lost. The one thing worth carrying into #2189's review: the census's second spelling (OpenSciForCausalLM, 7 models vs 121) is not waved through, because exact-key matching is a stated design of census_watch.py — it is a second reviewed entry that needs the repo list from a census run, not a case-fold.