LincPayandClaude Opus 5
d710176f36
dscr_p10 is the feature TW-01 fires on, and so the origin of nearly every alert an officer sees — but nothing had written forecast_point since the seeder. A headline number computed from demo data is worse than no headline number, because it looks identical to a real one. ForecastStrategy is a seam shaped like ScoringStrategy: the LightGBM quantile heads implement it later and the swap is one property. The forecast and the score answer different questions and fail differently, so they get separate seams. The method is fully explainable. Baseline is the median whole-month net position from the ledger, median so one festival month does not become the expectation, and the partial current month is discarded. Drift comes from margin_squeeze, else feed_cost_change, capped so one sharp month does not extrapolate into a cliff. Spread widens with the square root of the horizon and again for every input we did not have. Missing inputs widen the band, never lower the centre. A pessimistic P50 built on ignorance would manufacture breaches. An enterprise with too little ledger gets no path rather than a fabricated one, so dscr_p10 resolves NO_FORECAST visibly. forecast_point gains engine/model_version. Seeded rows carry neither, and udyam.forecast.trust-seeded decides whether dscr_p10 may fall back to them. Left true so the demo portfolio stays populated; with it false the picture is honest — 6 enterprises forecast, 136 NO_FORECAST, and trip-wires firing drops from 34 to 5. The forecast reads margin features and dscr_p10 reads the forecast, so features are computed twice per enterprise rather than letting either half read a previous run's answer. Seeder now writes 150 days of ledger, not 31: the baseline needs whole months and one month leaves nothing to take a median of. Ledger joins loans in the backfill pass, keyed on clientId. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>