The #292 and #365 taxonomy gates are not running at all while bbop-sqlite 403s

[realmarcin]

validate-strict is green on PR #702, and the reason it is green is worth writing down before it becomes invisible.

From the run log:

Downloading ncbitaxon.db.gz: 0.00B [00:00, ?B/s]
[taxon-ids] NCBITaxon is unavailable, so the shared-id check (#292) was skipped, not passed.
[gtdb-domain] NCBITaxon is unavailable, so the prokaryote-only check (#365) was skipped, not passed.

https://s3.amazonaws.com/bbop-sqlite/ncbitaxon.db.gz returns 403 Forbidden — verified from a developer machine on both HEAD and a ranged GET, so it is upstream and not a runner problem. A cache step cannot repair it: a cache only warms from a download that succeeds.

The degradation is correct. Both validators announce it, and after #702 the tests that need a real lookup skip with the same wording rather than failing. Nothing here is a bug.

The risk is duration. Two gates are off, and every CI run from now on is green without them. The whole point of the "skipped, not passed" wording is that somebody eventually reads it — and a message that appears in every run for months stops being read.

What this issue is for: a place to record that the gates are off, so turning them back on is an action someone takes rather than something that quietly never happens.

• Re-check whether bbop-sqlite serves ncbitaxon.db.gz again
• Once it does, confirm a CI run actually resolves an id (no 0.00B line, no "skipped, not passed")
• Consider whether an alternative source or a committed subset would make these gates independent of one host's availability

Related: #704 (the shared accessor and the skip gating), #707 (the cache key those runs would use).

[realmarcin]

The blast radius is much wider than this issue records, and a second CI gate is down

I filed this describing two skipped checks inside validate-strict. Measured again while working #605, it is bigger on both axes.

Every ontology, not just NCBITaxon

https://s3.amazonaws.com/bbop-sqlite/ncbitaxon.db.gz   403
https://s3.amazonaws.com/bbop-sqlite/go.db.gz          403
https://s3.amazonaws.com/bbop-sqlite/chebi.db.gz       403
https://s3.amazonaws.com/bbop-sqlite/envo.db.gz        403
https://s3.amazonaws.com/bbop-sqlite/uberon.db.gz      403
https://s3.amazonaws.com/bbop-sqlite/cl.db.gz          403

All six, HEAD, from a developer machine. This is the whole bbop-sqlite bucket, not one artifact. Locally it looks partial only because ChEBI and ENVO happen to be in ~/.data/oaklib already and GO is not.

label-correspondence has been failing on main since 2026-08-29

2026-08-29T02:03  failure  22673ba   <- since here
2026-08-27T19:16  success  80b882c
2026-08-27T07:27  success  c685fa6

It fails with 6250+ ADAPTER_ERROR rows, canonical='' on every term of every record — NCBITaxon, GO and CHEBI alike. Not drift: no adapter could be built at all.

So this is not "two checks inside one lane are skipping". It is two CI gates, one silently degrading and one failing loudly, and main has been red on the second for two days.

Three behaviours for one condition, now demonstrated

component	behaviour when the ontology is unreachable
shared_taxon_ids / ncbi_domain (#292, #365)	prints "skipped, not passed", exits 0
the tests gated in #704	skip with a reason
validate-products / label-correspondence	fails, 6250 ADAPTER_ERROR rows

Each is defensible alone. Together they mean "is the KB clean?" has no single answer right now, which is the thing #704 was supposed to have settled and only settled for the test suite.

Consequence for review

Any PR opened now inherits a red label-correspondence that has nothing to do with its contents. PR #712 is in exactly that position: every other check passes, and the records named in its failure log — AMD_Acidophile_Heterotroph_Network.yaml among them — are not in its diff.

Worth noting alongside #707: the OAK cache key never rotates, so whatever oaklib-Linux-v1 holds now is what CI will keep restoring. If it was first populated during this outage, it is an empty directory pinned indefinitely.

• Decide whether ADAPTER_ERROR-because-unreachable should fail or skip, and make all three components agree
• Re-check the bucket; if it does not come back, find another source for the SQLite builds