Baseball Logic
The Model Layer
The baseball logic underneath the product: expectation models, challenge value, overturn logic, rubrics, and ABS geometry.
ByColby Reichenbach
Overview
The model layer exists to make the product's baseball claims defensible.
AiBS does not rely on one giant model. The product uses a stack of baseball-specific logic: challenge event normalization, zone geometry, overturn estimation, run and win expectancy deltas, leverage framing, decision value logic, and summary rubrics for teams and umpires.
Some of those outputs are strongly model-driven. Others are heuristic or rules-based. Part of the job of this page is to make that distinction explicit instead of pretending everything is the same kind of intelligence.
The model layer is built so the ABS geometry path, calibration, and audit flow agree with each other. Production logic and evaluation scripts are supposed to tell the same story.
Expectation models
Run and win value are part of the challenge story.
Challenge evaluation in AiBS is not limited to overturn rate. The product also carries count-state deltas, run expectancy, win expectancy, and decision-value interpretations so a user can reason about when a challenge mattered and not just whether it succeeded.
Those value layers are not forced into every public surface equally. Fan-mode routes skip some of the heavier value joins when the page is not actually showing those numbers, which keeps the public product faster and clearer.
ABS geometry
The product now uses direction-aware challenge geometry.
The geometry was corrected so called strikes that should become balls and called balls that should become strikes are not bucketed symmetrically by mistake. The logic is now direction-aware and calibrated with audit scripts so the same geometry interpretation is used in runtime and evaluation.
That does not make the system perfect, but it makes it far more honest. Sparse challenge populations are now treated as a data reality instead of being confused with a geometry bug.