What does this equation mean?

The practical answer most teams converge on is a tiered budget, and it is worth writing the tiering down as an explicit equation rather than an implicit habit, because an implicit habit is what quietly erodes into “we stopped running the full suite” a few months in. If every merge triggers a cheap smoke tier of $n_1$ tasks at unit cost $c_1$ , run $k_1$ times a day, and a slower, more thorough tier of $n_2$ tasks at unit cost $c_2$ , run only $k_2$ times a day, the daily evaluation bill is simply $B_{\text{day}} = k_1 n_1 c_1 + k_2 n_2 c_2$. The first term is the per-merge tax — it has to stay small enough that engineers do not start skipping it, which is the single most common way a CI gate quietly stops functioning. The second term is the trust budget — infrequent, thorough, and the number that should scale up before a release rather than on every keystroke. Braintrust’s continuous-evaluation documentation reports exactly this kind of tiering in its online-scoring guidance: score at somewhere between one and ten percent of traffic for high-volume applications, but score one hundred percent of traffic for flows judged critical enough that a missed regression is unacceptable [ 7 ] . That sampling rate is itself a budget decision made the same way — a cheap, wide net most of the time, and a full, expensive check only where the cost of missing something is highest. Writing the split down as two explicit numbers, rather than letting it happen ad hoc, is what keeps the fast tier fast enough to actually run on every change and the slow tier honest enough to actually catch what the fast tier cannot.