feat(inference): add benchmark performance guardrails

[TobiBu]

Summary

• add performance_guardrails module for optimization/VI benchmark threshold checks
• add runtime/objective threshold dataclasses and pass/fail result object
• add unit tests for pass/fail regression scenarios
• export guardrail APIs and document usage in inference workflow docs

Validation

• pre-commit passed on changed files
• compileall passed for module and tests

[Copilot]

Pull request overview

Adds an inference “performance guardrails” utility to evaluate benchmark results against configurable runtime/objective thresholds, with tests and documentation so regressions can be detected early in CI or local benchmarking workflows.

Changes:

• Introduces rubix.inference.performance_guardrails with threshold dataclasses and pass/fail check helpers for optimization + VI benchmarks.
• Exports guardrail APIs from rubix.inference for public use and adds Sphinx docs coverage.
• Adds unit tests covering pass/fail scenarios for both optimization and VI guardrail checks.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
rubix/inference/performance_guardrails.py	New guardrail checking utilities and threshold/result dataclasses.
rubix/inference/__init__.py	Re-exports guardrail APIs at the package level.
tests/test_inference_performance_guardrails.py	Unit tests for guardrail pass/fail behavior.
docs/rubix.inference.rst	Adds the new module to Sphinx API docs.
docs/inference_workflows.rst	Documents intended usage pattern for guardrails in workflows.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

ObjectiveThresholds mixes optimization loss thresholds (max_final_loss/max_best_loss) with VI objective thresholds (max_final_objective/max_best_objective), but each guardrail checker only evaluates a subset. As written, setting the “wrong” fields for a given checker will be silently ignored and can incorrectly report passed=True. Consider splitting this into two threshold dataclasses (optimization vs VI), or add explicit validation in check_ifu_optimization_guardrails/check_vi_guardrails to raise a ValueError when irrelevant threshold fields are set.

[TobiBu]

@copilot apply changes based on this feedback

[TobiBu]

@copilot can you try again to apply changes based on the feedback in this PR?

[Copilot]

@copilot can you try again to apply changes based on the feedback in this PR?

The changes are applied in commit 9bffb0e. ObjectiveThresholds has been split into two typed dataclasses:

• OptimizationObjectiveThresholds(max_final_loss, max_best_loss) — accepted by check_ifu_optimization_guardrails
• VIObjectiveThresholds(max_final_objective, max_best_objective) — accepted by check_vi_guardrails

This removes the silent-ignore issue: passing the wrong threshold type to a checker now results in a type mismatch rather than incorrect pass/fail reporting. Tests and docs have been updated accordingly.