What happened, and what to score, are two different things. A folder states when each period ran. Which part of it to analyse is a decision about your protocol — a solution takes time to arrive, and a period that ran forty minutes is not forty minutes of the same thing. Where a producer sends that decision, it is used and this section leaves it alone.

Which periods wait for a solution is yours to say. A drug has to arrive; a depolarising challenge is already there. So the delay applies to the period kinds you tick, listed above from what the folder actually contains — a list somebody set, not a rule reading letters out of a name. The convention this replaces exempted anything whose label contained hi, which caught histamine, missed chelerythrine, and would have silently begun trimming every high K+ window the day someone renamed it KCl.

Three numbers, and nothing decided behind your back. The baseline is measured backward from its end, because the minutes just before the treatment are the ones the treatment is compared against. Every other period starts after the delay you gave it — the one above, or none — and runs a fixed length. Periods do differ here; what has gone is the page deciding which, from the letters in a name.

A window too short to mean anything is flagged, not quietly used. Applying one delay to every period will leave some of them with almost nothing — a brief challenge at the end of a recording is the usual case. That is reported here rather than hidden, because the alternative is a result computed over thirty seconds and labelled like the rest.

How much coordination is here, measured against a rate-matched null. Each ROI's own train is circularly shifted by its own random lag, which holds its rate and its burstiness and destroys only cross-ROI phase — so what survives is coordination beyond what the recording's rate explains.

K is a scan, not a choice. The floor for how many ROIs make an event moves the headline by an order of magnitude, so every K is shown and none is marked as the answer. Quoting one of these numbers means naming its K.

Baseline only. Coordination properties are not taken from a treatment — that is what the instrument is pointed at, and sourcing them from it assumes the answer. A recording with no declared regions is assessed whole, and it says so.

The machine proposes; you dispose. The assessment found moments where more ROIs fired together than its rate-matched null explains. Those are candidates, not findings — and every number the simulator is parameterised with is currently a median over candidates nobody looked at.

You are judging a sample, and that is deliberate. On this lab's own 84-recording folder there are 3,567 candidates at K=3 and still 641 at K=8, so nobody annotates them all. What a sample buys is an agreement rate: how much of what the machine proposed you believed. That rate scales the event frequency the simulator plants, and it is reported per K — so you read K off what you confirmed rather than picking it before looking.

At most a few per recording. One recording in this lab's folder carries 200 candidates where the median is 8. Uncapped, a sample spends your whole session on whichever recording is busiest and the agreement rate becomes a statement about that one slice.

Every verdict records what you were looking at — the time window, the ROI ordering, the stream — because a judgement is a property of the recording, the rendering and the observer together. A verdict without its view cannot be reproduced or disputed, and the file refuses to hold one.

"Can't tell" is a real answer. It is kept out of both sides of the agreement rate: a candidate you could not judge is evidence about the rendering, not about the candidate.

Nothing here is a recording of anything. Event times are drawn from the model in bugarach.simulate, re-implemented for this page — same model, a different generator, so a seed reproduces in this browser and does not match Python's numbers.

The settings you land on are measured, not chosen. Rate, ROI count, participation and jitter come off 84 untreated slices, and every one of them used to be a guess that made coordination easier than it is — six ROIs with a third of a second of spread, not half the field firing together. The old guesses are on the switches, and worth a look.

The windows are labels, not effects. The statistics are identical inside and outside every one of them. Simulating a treatment would spend the effect the experiment exists to measure — so the drug is a name on the axis and nothing more.

The step that makes this a loop. The other three ask what is in a recording; this one asks whether the instrument reading it is any good. It sweeps one setting of each detector ticked above, holds the rest of their settings where the Detect step below has them, and scores every result against the events that were planted — so a number here is right or wrong rather than merely produced.

The tick list is this panel's own. Unticking a detector here does not remove it from what Detect runs, and vice versa: fitting an operating point and using one are separate decisions, and a sweep you skipped for cost is not a detector you stopped believing in.

Only on a folder this page invented, and that is the reason the simulate step exists. Your own recordings have no answer key: nobody knows which moments in them were coordinated, which is what the detector is for. Tune where the truth is known, then point the tuned instrument at the recordings where it is not.

A best value at the end of the range is not a best value. It is the sweep saying it stopped too early, and it is reported as that rather than as an answer — a boundary value has been published as a calibrated setting before. When it happens, that block offers to extend the grid past the end it hit and sweep again; the sweep range boxes above are the same thing done deliberately, before pressing Sweep.

Each detector has exactly one swept setting, and the range boxes do not change that. The other settings are held wherever the Detect step has them, so a sweep answers "what does this one knob do to these settings" — not "what is the best this detector can do". A grid that scores the same at every setting is that limit showing: the knob being swept is not what decides the answer, and no width of range will help.

The step above answers one question; this one produces the file. Every recording in the folder, every stream and every region the folder declared, with the detectors ticked above — one row per event per detector, with no consensus merging, because which detector fired is the information a merged row throws away. Until 2026-08-23 this ran all six whatever the tick list said, so the one control on the panel governed the picture and not the file.

A recording that produced nothing still appears. Not as a row — it has no events to write — but in the roster inside run.json. Absent rows are a finding and an absent recording is a bug, and a file where those two look alike cannot tell you which you are holding.

The sidecar is why this is usable in six months. Times alone do not say what produced them, so run.json carries the roster, the frame interval of each recording, and every detector's settings. It says null for the generator spec, the chosen K and the seeds when a folder came off disk rather than out of the simulate step — a question that was asked and had no answer, rather than one never asked.

These are detections, not events. The file records what six instruments called on your recordings at the settings currently set above. Nothing here has been scored against a known answer, because your recordings do not have one.

The loop, in the order you actually walk it. Assess a baseline → simulate from what you measured → compare the simulation with the recording → sweep a setting against the planted events → Save these settings → open your own folder → Load settings… → Detect. The two middle steps used to be a variable this page kept alive behind your back; they are a file now, and the file's name and its own rows say which data set it was fitted on. Opening a folder clears what was in the boxes, because a number fitted on one data set is not a fact about the next one.

A settings file names its stream, and will not be applied to another. The stream is chosen when the folder opens and one is in play at a time. Loading a file fitted on fast while slow is in play is refused with the reason, rather than quietly running a threshold on the signal it was not fitted for — FOUNDATIONS §9: coordination under TTX moves in opposite directions in the two streams, so this is a different answer and not a rougher one.

RateDetect asks how fast the population is firing. It flags moments when the pooled rate rises above its own local context — so a slice that fires steadily has no events, however tightly aligned it is.

Checked against the Python exactly. It draws no random numbers, so this browser copy is compared to the port the rest of the project cites at 1e-9 on every event it finds. A mistake here cannot pass as sampling noise.

The settings are what the project benches at, not what your preparation needs. Finding those is what the simulate step above is for: measure, simulate from what you measured, tune against planted events, then point the tuned instrument at everything.

SCE is the blunt one, and that is the point of having it. It bins ten seconds at a time — against LoCo's one and CoactDetect's two — and asks whether a stretch of recording was busier than this recording usually gets. Not "did these cells fire together" so much as "was something happening here".

One bar for the whole window. The other two re-estimate their threshold as they go; this compares every bin to the same number. That makes it slower to be fooled by a local rate change and worse at finding a small event inside a busy stretch.

It reports where the BIN started, not where the first cell fired. A ten-second bin is a ten-second answer, and the width travels with it so nothing downstream mistakes the left edge for an onset. That convention once read zero recall against a scorer treating detections as points, and it is kept rather than quietly improved.

CoactDetect asks the same question as LoCo and answers it with different arithmetic. Both count distinct ROIs per bin and both build a local null by shuffling. LoCo keeps bins above a high percentile of the shuffles; this turns each bin into a z-score against the shuffles' mean and spread, and keeps the ones whose p clears alpha. They part company in the tails, which is where coordinated events live — so running both and comparing is worth more than picking one.

Alpha is per bin, not per recording. At 1e-4 and a two-second bin, a forty-minute recording tests twelve hundred bins, so a handful of false positives is the expected behaviour of the setting rather than a fault. The simulate step is where you find out how many.

Sampled, and checked accordingly — the coactivity is compared to the Python exactly, the episodes are compared exactly once significance is fixed, and the p-value arithmetic and its erfc are checked on their own rather than through a hundred random draws.

LoCo asks how many cells fired together, against what this recording does the rest of the time. It counts distinct ROIs per bin — one count per cell however often it fired, because one busy cell is not coordination — and compares that to a bar estimated locally by shuffling this recording's own events.

This is the first detector here that guesses. The bar comes from a hundred shuffles, and this page's random numbers are not the Python's, so the two agree on the bar only to sampling error. What is checked exactly is everything either side of it: the counts are identical, and given the same bar the events are identical to 1e-9. The bar itself is checked by sampling harder and confirming the disagreement shrinks — which it does, and which a wrong answer would not.

The floor is three ROIs and is not adjustable. Coordination found in a treatment window is evidence about the preparation, not a false-alarm rate to raise the floor until it disappears — this project has talked itself into that once and the setting is fixed here so it cannot happen by accident.

This detector is not in this build. It is derived from another laboratory's published tool, and how it should be named and credited here is an open question this project has not finished answering. It is withheld until that is settled, rather than shipped under a name that would prejudge it.

Nothing is lost from work you have already done. A detections.csv that carries its rows still draws here, and the Python package still runs it — only this page's ability to start a new run with it is off.

SPIKE-synch asks how aligned the spikes are, whatever the rate. Every spike gets a coincidence value between 0 and 1 — the fraction of other ROIs with a spike inside a window that adapts to how densely each one is firing. A slice that never speeds up but tightens its timing shows here and not in RateDetect, which is the reason to run both.

The cap is the part worth setting. It is the widest the adaptive window may ever open, so it decides what counts as "together": 0.25 s for a fast stream, 0.5 s for a slow one. Without it a busy ROI would look coincident with everything.

Checked against the Python exactly, at 1e-9, on the coincidence profile and on every event — this is the second detector here that draws no random numbers, and the same reasoning applies. Events whose C is near-total and narrow and shared by most of the field are reported separately: that combination is a stage knock, not coordination.

This is the only step that does not run in your browser. Everything else on this page runs where you are standing and reaches nothing. Training a network needs more than a page can carry, so it runs in a process on this machine — reachable only from this machine, reading no file, and given nothing but the numbers shown above. The published page cannot reach it and does not show this panel at all.

It fits on a simulation, never on your recordings. The data set is generated from the statistics measured in the assess step, so its events have known times and a score means something. Fitting on the recordings you are about to analyse would spend the very effect the experiment exists to measure.

Every score here is on a fold the model never saw. The data set is split first, the model is fitted on the rest, and the held-out fold is scored — the same procedure the published comparison used, reported across folds with its spread rather than as one number.

There is no re-tune button, and that is deliberate. The operating point is chosen on held-out data and travels with the model. Re-picking it on the recording being analysed would hide exactly the failure this is measured against.