Reading the operating point…
ChoonSettings
demoThis build is a demo. The catalog and detections are a fixed sample.Scopereading…Sound is used for one thing: a short tone when a long scan finishes while this tab is in the background. The A/B listening check plays audio either way, because there the sound is the evidence.Reading the operating point…
What operating point is the queue being graded against, who is told about it, and who changed what?
auto_high and review resolve to the same operating point on the only corpus they have been fitted on (calibrate.py:73-75); the defaults differ arithmetically but the separation is not measured, so only one confidence band is real
So the console draws one confidence band, because one is measured.
Sample data — The service did not answer, so these are the constants the frontend applies — taken from calibrate.py:76-78 — rather than the tenant’s stored operating point. Source: src/lib/choon.ts. Nothing below was measured from your catalog.
Changing a threshold, and previewing its effect on the queue, is not wired here.
PUT /api/settings/operating_point exists (catalog_router.py:367), validates the value, and is reachable from this browser: the settings proxy forwards PUT as of 2026-08-24. Until then this sentence read “this app’s proxies are GET-only, so the call is printed rather than offered”, which is why the curl below still stands where a control belongs — the transport landed and no control here uses it yet. Whatever wires it must take the bounds, the validation and the min_windows < 2 warning from the server’s own response body, which publishes all three; the proxy adds no bound of its own and none may be invented here. The preview §13.9 asks for is a separate and still-real gap: it needs the queue re-scored at a candidate threshold and no endpoint does that — a preview computed from the rows already on screen would preview a filter, not a decision boundary.
curl -s -X PUT "$CHOON/api/settings/operating_point" \
-H 'content-type: application/json' \
-d '{"value":{"review_threshold":0.015,"auto_threshold":0.05,"min_windows":2}}'The validator refuses min_windows < 2 with the reason attached: the supporting-window rule cuts the item false-positive rate from 2.97% to 0.08% for one point of recall, and the score alone cannot reach that rate at any threshold without collapsing recall. Raising the threshold buys nothing here — precision is flat across the range.
No alert rule is stored for this scope.
alerts is a settable key (catalog_router.py:338) and this tenant has not set one, so the value is unset rather than empty. §14.9 says the rules are about claim state and not volume — an alert on “more detections than usual” fires on a bigger scan, which is not news. Nothing delivers a notification in this build either way.
No ownership defaults are stored, so newly ingested recordings inherit WW and an open window.
ownership_defaults is settable and unset. The windows and territories that ownership_ok actually reads live per recording in the catalog — a null territory there is why a detection evaluates to Unknown rather than to In force, and it is fixed on the recording, not here.
no disposition has been recorded in this scope
The audit endpoint answered and its table is empty for this tenant — an empty log, not an unreachable one. Every disposition made in the queue writes a row here with the model version, catalog version and thresholds in force at the time, which is what makes it usable by counsel rather than merely reassuring.
An unstamped build reports a null version rather than a version string somebody could cite (monitor_deps.py:257). This deployment reports model —, catalog —, revision —.