fix(classifier): validate confidence_threshold range, take percent in the UI #47

Merged
alee merged 1 commits from fix/confidence-threshold-percent-ui into main 2026-09-06 23:36:48 +00:00
Owner

classify_zero_shot returns a 0.0-1.0 probability, but the admin UI's confidence_threshold field took a raw number with no conversion and no bound -- typing the intuitive "80" (meaning 80%) stored literal 80.0. Since no real confidence score can exceed 1.0, that silently made every single classification read as below-threshold and fail, with the failure only surfacing on the next service restart (config loads once at startup).

Caught live 2026-09-06 before it took effect: the running process still had the previous config loaded, but the corrupted value was already sitting in config.local.yaml waiting for the next restart. Corrected the live overlay directly via the admin API as an immediate mitigation; this PR is the actual fix.

Two changes:

  • classifier.encoder.confidence_threshold now validates to [0.0, 1.0] at config load, matching every other new knob's fail-closed pattern in this project -- the backstop for any caller, not just the UI.
  • The admin field now takes 0-100 (human-natural) and converts to 0.0-1.0 at the save boundary; loading a stored value converts back to a percent for display.

New regression tests confirmed failing on the unfixed code, passing after. Full suite: 1503 passed, 0 failures.

classify_zero_shot returns a 0.0-1.0 probability, but the admin UI's confidence_threshold field took a raw number with no conversion and no bound -- typing the intuitive "80" (meaning 80%) stored literal 80.0. Since no real confidence score can exceed 1.0, that silently made every single classification read as below-threshold and fail, with the failure only surfacing on the next service restart (config loads once at startup). **Caught live 2026-09-06 before it took effect**: the running process still had the previous config loaded, but the corrupted value was already sitting in `config.local.yaml` waiting for the next restart. Corrected the live overlay directly via the admin API as an immediate mitigation; this PR is the actual fix. Two changes: - `classifier.encoder.confidence_threshold` now validates to `[0.0, 1.0]` at config load, matching every other new knob's fail-closed pattern in this project -- the backstop for any caller, not just the UI. - The admin field now takes 0-100 (human-natural) and converts to 0.0-1.0 at the save boundary; loading a stored value converts back to a percent for display. New regression tests confirmed failing on the unfixed code, passing after. Full suite: 1503 passed, 0 failures.
alee added 1 commit 2026-09-06 23:36:33 +00:00
classify_zero_shot returns a 0.0-1.0 probability, but the admin UI's
confidence_threshold field took a raw number with no conversion and
no bound -- typing the intuitive "80" (meaning 80%) stored literal
80.0. Since no real confidence score can exceed 1.0, that silently
made every single classification read as below-threshold and fail,
with the failure only surfacing on the next service restart (config
loads once at startup).

Caught live 2026-09-06 before it took effect: the running process
still had the previous config loaded, but the corrupted value was
already sitting in config.local.yaml waiting for the next restart.

Two fixes:
- classifier.encoder.confidence_threshold now validates to [0.0, 1.0]
  at config load, matching every other new knob's fail-closed pattern
  in this project -- the backstop for any caller, not just the UI.
- The admin field now takes 0-100 (human-natural) and converts to
  0.0-1.0 at the save boundary; loading a stored value converts back
  to a percent for display.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VRQXz5SYZYVWscxS1QqF6U
alee merged commit 2954ea1c34 into main 2026-09-06 23:36:48 +00:00
Sign in to join this conversation.
No Reviewers
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: alee/6krrt#47