Check reference
Investigate slow proof slices with comparable measurements
A slow solver run can make verification impractical without indicating a false requirement. solver_latency_clean highlights component slices that exceed the configured time budget.
Read the timing in context
The default threshold is 60 seconds, configurable through project.checks.solver_latency_clean.threshold. The check evaluates recorded per-slice wall-clock durations. Large contracts, many guarantees and difficult temporal formulas can increase runtime. A timeout, a counterexample and a completed but slow proof are different outcomes. Inspect the solver verdict separately from the timing warning.
Illustrative example: one expensive component
A component contains both a retry state machine and unrelated reporting rules. A timing report identifies that component as slow, but does not tell you which formula or responsibility causes the cost.
Investigation sequence:
1. Record the component, revision and solver settings.
2. Repeat its analysis under quiet host conditions.
3. Inspect the generated contract and difficult formulas.
4. Compare timing after a justified simplification.
No timings in this example are benchmark results. A useful comparison holds inputs and environment steady enough to attribute the change.
Measure before splitting the model
Run the component analysis and inspect its structured result. Tighten unnecessarily complex formulas first. Split a component only where the architecture has a real boundary, with truthful interface assumptions and guarantees. Raising a threshold may be a legitimate budget decision, but it does not make an expensive proof easier to maintain.
proof realize specs/system retry --format json
proof audit --check solver_latency_clean --verbose
Contention can make a result inapplicable
The check can skip when concurrent Proof processes or excessive host load undermine the measurement. Recorded rows marked as concurrently measured can also be excluded. Those skips request a quieter rerun; they are not fast-proof results. Detection is best effort and unavailable host signals do not establish an idle machine. A successful timing check says the measured slices meet policy, not that the model is complete or the system correct.
Follow the evidence
Rerun the named slice in a comparable environment before changing architecture or thresholds.
Review one slow proof slice. Bring the model, timings and solver settings so we can assess whether the next step is a quieter measurement, a formula change or a justified decomposition.