Where a solve spends its budget

Route A declines, route B declines, route C decides. Those attempts run one after another, so a flame graph that draws the decliners inside the winner reverses the order they happened in. Inside one route the nesting is real: a theory check contains a simplex solve contains its pivots. And a refinement loop is one row with a count, because nobody reads forty thousand boxes.

So the solver emits rows, not a tree. Each row names its parent and the kind of edge — nested, fell_through, or refinement_round — and every view below is derived from the same rows.

Four fields carry rules rather than data. A span is written on open, so closed_at_ns: null is a run that died inside it. A budget that ran out is exhausted with the bound in bound, never declined. A deterministic counter travels beside the wall clock, and reads null where none applies. A loop is one row with loop_count.

The same 20 files, the same binary, twice in a row on one host with nothing else on it. 0 verdicts moved. The deterministic counter was identical on 20 of the 20 files that carry one, which is what makes the work axis comparable between runs at all.

Wall clock moved by 1.8% at the median and 25% at the worst — and the worst cases are files that take a few milliseconds, where one millisecond is a quarter of the run. Across the 5 files over a second the largest move was 1.5%. Read a timing difference below that as the machine, not the solver.