Skip to main content

Honesty about uncertainty and model limits

The model limits: what happens with little history, the structured warnings, and why every recommendation is auditable, with no black boxes.

The design principle​

With little history, no statistical method "guesses" the future. What distinguishes an honest system from one that projects false confidence is not how much it knows, but how much it declares that it does not know.

AInventory is designed so that every recommendation comes with explicit information about:

  • The quality of the SKU's history (level in the statistical cascade).
  • Which distribution the system chose and why.
  • Whether the forecast appears to be biased.
  • Which policy won and what the expected cost of each was.

The goal is that the planner never has to blindly trust a number: they can always trace where it comes from.

The structured warning system​

Warnings follow a four-severity structure. Each one indicates the SKU's level in the statistical cascade and the degree of confidence in the recommendation:

BLOCKING — No history​

The system cannot produce any recommendation for this SKU. The BLOCKING severity means that if the planner accepts the recommendation without intervention, they are making a decision with zero quantitative backing. The SKU is flagged for mandatory manual review.

HIGH — Little history​

The system produces a recommendation, but the statistical parameters are estimated with high uncertainty (parametric bootstrap by Method of Moments with very few observations). The chosen distribution may be right or wrong; with so few data points, there is no way to distinguish that confidently. The planner should treat the recommendation as an initial proposal that requires review.

MEDIUM — Moderate history​

The estimate is more reliable (stabilized MLE) but still moderate. The Shapiro-Wilk test runs and may or may not reject normality. If it does not reject, the Normal distribution is accepted; if it does, which alternative distribution was used is recorded.

INFO — Non-normal errors (moderate history)​

The Shapiro-Wilk test rejected the normality hypothesis at the moderate-history level. The system used Gamma or Lognormal (according to the argmin AIC) instead of Normal. This warning is informational — it does not imply the recommendation is wrong — but it signals the planner that the error distribution is not symmetric.

INFO — Empirical bootstrap active (mature product, growing history)​

The SKU is at the mature-product level but with a moderate number of available history rows. Non-parametric bootstrap is technically valid, but its quantile coverage improves with more data; the recommendation is reliable and the planner may want to monitor it as history grows.

Traceability of every recommendation​

For each processed SKU, the system records and exposes to the planner:

  1. Assigned cascade level and the corresponding n.
  2. Chosen distribution (Normal, Gamma, Lognormal, or non-parametric bootstrap) and the selection criterion (AIC, Shapiro-Wilk, or default).
  3. Winning policy and optimal k*, along with the expected cost ranking of all five policies.
  4. Active warnings with their code and severity.
  5. Forecast parameters used as the basis (if the forecast shows apparent bias, this is visible in the historical errors).

None of this data is hidden inside the computation engine: it is part of the standard optimizer output and is presented alongside the recommendation.

Manual overrides and audit trail​

When a planner decides not to follow the system's recommendation — due to commercial context, supplier negotiation, or other criteria the model cannot capture — they can record a manual override. The system requires a justification of at least 10 characters before accepting the override.

All overrides are recorded in the audit history with:

  • The value recommended by the system.
  • The value entered manually.
  • The written justification.
  • The user and timestamp.

This allows retrospective audit of whether overrides improved or worsened results versus what the system would have done automatically. For the operational details of how to record an override, see the guide Manually adjusting replenishment.

Design philosophy

The combination of structured warnings, method traceability, and override audit responds to a design decision: the system should be an auditable assistant, not an opaque oracle. The planner has the final word; the system has the obligation to show its work.