CI performance gate

Gate releases on a repo-owned benchmark corpus compared in one paired run, with thresholds designed so a faster release can never fail. Choose thresholds and inconclusive-result policy before measuring.

Corpus

• Own the gold set in-repo, modeled on the consumer's real workload shapes (dispatch, closures, error paths, lookups, folds, load). Self-contained: no consumer checkout, no cross-repo secret, no revision pin. Expected results are hand-derived from the contract, never captured from the engine under test.
• Every timed cell carries a committed tier/threshold classification; the gate fails untiered cells. Adding a cell is therefore a forced two-run sequence: land the benchmark untiered → dispatch a run that must fail (upload artifacts with if: always() — that failing run's output is the classification profile) → commit tier + profile + any pinned digests together → second run shows the cell judged green.

The two axes behave differently

• Bytes and allocations are measured averages, not universally exact per-op constants. Pools, input mix, runtime work and integer rounding can change them. Establish stability for the actual workload and pinned toolchain before enforcing exact bounds.
• Latency is a sampled statistic. Use paired/interleaved runs with a control, fixed concurrency and recorded hardware/toolchain. Measure the runner's noise floor; hosting alone does not make a machine quiet.
• Treat local measurements as exploratory when their noise exceeds the gate's tolerance. Record uncertainty rather than declaring an unmeasured pass.
• Calibrate thresholds on representative repeated data. Do not license a threshold from one favorable run.

Thresholds