fix(forecasting): cap trend_ratio by v_rec magnitude when v_prior==0 (#1508) #1679

Merged
lekss361 merged 1 commit from fix/trend-ratio-vprior-zero-1508 into main 2026-06-17 17:45:14 +00:00

1 commit

Author SHA1 Message Date
cf36151dbc fix(forecasting): cap trend_ratio by v_rec magnitude when v_prior==0 (#1508)
All checks were successful
CI / changes (push) Successful in 10s
CI / changes (pull_request) Successful in 7s
CI / backend-tests (push) Has been skipped
CI / frontend-tests (push) Has been skipped
CI / openapi-codegen-check (push) Has been skipped
CI / backend-tests (pull_request) Has been skipped
CI / frontend-tests (pull_request) Has been skipped
CI / openapi-codegen-check (pull_request) Has been skipped
When v_prior == 0 and v_rec > 0, the old code unconditionally assigned
trend_ratio = 2.0, producing an artificial 2x jump even for districts
with negligible recent velocity.

New formula:
  ratio = 1.0 + min(1.0, v_rec / _REF_VELOCITY) * (_TREND_CAP_VPRIOR_ZERO - 1.0)

Where:
  _REF_VELOCITY = 10.0   (monthly flats/corpus — EKB "well-performing" benchmark)
  _TREND_CAP_VPRIOR_ZERO = 1.5  (max ratio for the v_prior==0 case)

Tiny v_rec (e.g. 1 flat/month) → ratio ≈ 1.05 (near neutral)
Large v_rec (≥ 10 flat/month) → ratio → 1.5 (capped, below old hard 2.0)

v_prior > 0 branch is unchanged.

Also fixes pre-existing ruff violations in the same file (E401 multi-import,
E701 inline colon, E722 bare except, F401 unused import) so ruff check passes clean.
2026-06-17 20:29:46 +03:00