locs is a field name, not a value — retract yesterday's todo, file the real one

[syncytium2]

Retracts the todo landed in #353. It claimed cicada_detect anchors on "the wrong landmark" for folder input and proposed a bench run at onset_field="peak". The anchor is correct, and that run would have moved the detector onto the peak — the direction this project deliberately came from.

What is actually going on

locs is a legacy field name and the value in it changed. From MATLAB findpeaks — [pks, locs], plot detected peaks at x=locs, y=pks — so in the event store archive locs is the peak time. Coordination wants the onset, not the peak, so t50rise went into the field still called locs.

"when i manually coded the early versions of the coordination routines, i just passed locs. the field name is probably locs. pretty quickly we put t50rise into the coordination data field locs. hence the crisis" — Tony, 2026-08-28

The consequence nobody had looked for

rise_durations() computes the rise interval as locs - t50rise. On a store that is peak - onset. On a folder those two fields hold the same value, so it returns zero for every event.

Verified on dataset.current(), 20240708_13 fast:

rise_durations   2215 events   min 0.0   max 0.0   all zero
peak - locs      median 0.30 s   max 2.20 s     <- the real interval, unread

The interval is loaded into Stream.peak and nothing reads it — has_peak has no callers anywhere in the tree.

Latent, not live. OPERATING_POINTS["cicada"] uses fixed active_duration_sec=1.0, so rise_durations() is off the deployed path and no published number is affected. It bites active_duration_mode="per_event", duration_field="rise_dur" — the mode explore_sce uses to tame long SLOW transients — where every cell is marked active for zero seconds, and a detector that then finds nothing looks like a detector that found nothing.

Why the suite missed it: test_rise_durations_matches_definition runs on SLICE.fast, a store fixture, where locs genuinely is the peak. The function is correct there and wrong on the input the project actually uses. Nothing loaded a folder and asked what a duration came out as — so this adds that, on a synthetic folder, xfail(strict=True) so it documents the trap today and fails loudly if someone fixes it without removing the marker.

Not the producer team's zero-width

<darkroom>/constellation/cicada_zerowidth_explainer is a different zero: the detected event's output width_sec collapsing when member onsets fall outside the peak window. Its floor is already implemented in this port. Theirs is the output width; this is the input duration. The todo says so, because conflating them is the obvious next mistake.

Two overclaims about the Cossart corpus, also corrected

Same misreading, spilling onto a third party:

• The importer called their raster "the authors' own inference (CICADA / DeepCINAC)". That lab publishes both tools, but nobody here has read their pipeline documentation, and naming a method on a guess is the class of error The attribution memo you replied to credits the wrong laboratory — do not ship it #292 exists about. It now says only that the data arrived binarised, and says explicitly that it does not know which step produced it.
• Both the importer and the todo now state that this lab's locs/t50rise history is ours and transfers nowhere — "this doesn't apply to the cossart dandiset. i have no clue what's in there." The two corpora share a loader and nothing else.

Verification

Suite 1454 passed, 16 skipped, 1 xfailed. Sapper clear. No detector is touched — the retracted todo is a standing demonstration of what changing one on a misreading would have done.

🤖 Generated with Claude Code