Eight of the nine readable deposits are geometrically heterogeneous

Run 2026-09-20. Code: gate/verify_geometry.py. Output: gate/verify_geometry.json. One channels table per subject, counting BIDS channel types, across every deposit gate/RESULT-SOURCES.md had verified as carrying stimulation with per-trial current.

Control: ds004370, the deposit NS-0012 and NS-0013 were computed from, must return exactly seven subjects all ecog_grid. It did, and the run aborts if it does not.

Question or issue resolved

Whether the deposits this register has verified as usable actually share a recording geometry — and whether "verified as carrying stimulation with per-trial current" was ever evidence that they do.

The sourcing checklist asked whether a deposit carries a real perturbation with its intensity recorded. It never asked what the electrodes were. ds005448 had just shown that the answer can differ within one deposit: five of its subjects record from subdural grids and eight from depth electrodes, and the reading pipeline silently computed the latter eight to nothing.

The open question was whether that was one bad deposit or a property of the supply. This run checks every verified deposit, subject by subject, before any further one is computed.

The survey

Of the ten, one is homogeneous, eight are heterogeneous, and one (ds007703) has unreadable channel tables. The single homogeneous deposit is ds004370 — the one the register had already computed. That is why this went unnoticed: every check the sourcing process applied was passed by ds004370, and ds004370 is the exception.

Two independent confirmations of the ds005448 split: this probe reads its channel tables and reports 5 grid against 8 depth; the reading pipeline independently failed to load the same eight subjects when asked for grid channels. The methods share no code.

The case the existing guard cannot see

prios.load_subject already refuses a subject whose requested geometry is absent, which is what caught ds005448. That guard is blind to the harder case.

Where a geometry is absent, asking for it returns nothing and the failure is detectable. Where both are present — a grid and depth electrodes in the same patient, or scalp EEG recorded alongside depth electrodes — asking for either returns real channels and computes without error. The two answers differ, for the same patient, in the same state, under the same stimulation, and nothing in the output says which half of the implant produced the number.

UMCU59 is the worked example: 47 good grid channels and 16 good depth channels in one implant. Both filters compute. Neither result is wrong. Only one of them is the number you think you have.

Fixed by a second guard that refuses a subject carrying at least 8 good channels of a geometry the filter is dropping, unless ALLOW_GEOMETRY_SUBSET is set — computing one geometry of a mixed implant is legitimate, but it is a decision, not a default. The threshold is held equal to the one this probe uses to call a subject mixed, and a test asserts they stay equal: at the first attempt the probe called UMCU59 mixed at 8 while the reading path waved it through at 20.

The two guards are ordered, and the order is load-bearing. The empty-set guard runs first, so a subject whose only geometry is the one not requested is reported as a mismatch rather than as a mixed implant.

What this does not change

• NS-0012, NS-0013 and NS-0026 are unaffected. ds004370 is homogeneous grid; the three ds005448 subjects behind NS-0026 are homogeneous grid.
• The CHOCS protocol result is unaffected. RESP0749 and RESP0800 are both pure depth, so CHANNEL_TYPES = {"SEEG"} captured every electrode channel they carry and nothing was silently dropped. This was checked rather than assumed, because the deposit is mixed across its six subjects and the two used could have fallen either way.

A second heterogeneity, found on the way

ds004774 is not readable by this pipeline for four of its fourteen subjects, and the reason has nothing to do with geometry. The Mayo subjects store recordings as MEF3 (.mefd directories, one compressed file per channel); the UMCU subjects store BrainVision. The byte-offset range reader this project uses applies to BrainVision only. The task label differs too — ccep against SPESclin.

So a single deposit can be heterogeneous in geometry, file format and task vocabulary at once, and the subject count in the census speaks to none of them.

Limitations, stated

• One channels table per subject. A subject whose runs differ in montage would be reported by its first table alone. The reading path intersects channel sets across runs and would catch that separately, but this probe would not report it.
• scalp_eeg is treated as a geometry, per METHOD 3.3, so a subject with simultaneous EEG and depth electrodes is reported mixed. That is the intended reading of 3.3, but it is a stricter standard than a reader might expect, and it makes five deposits require an explicit declaration that they would not require if scalp recordings were excluded from the definition.
• ds007703 and ds005558 were already off the usable list; their rows are reported for completeness, not as candidates.
• The probe reads channel types, which is what BIDS records. It does not verify that a type label matches the physical electrode, and no deposit here was cross-checked against its electrodes table or coordinate system.