Review release benchmark combinations while preserving public scientific coverage #322

Summary

Target v0.5.3. Review the release benchmark inventory for scientifically justified reductions in repeated combinations, while preserving comprehensive public-operation and distinct algorithm-path coverage, supported dimension regimes and numerical edge behavior.

Current State

#301 narrowed peer measurements but also expanded public API coverage. The local v0.5.2 plan has 2,673 measurements versus the former 1,422: 1,254 shared baseline cases, 16 peers, and 1,403 current cases. At 3-second warmup plus 5-second target measurement, nominal acquisition is 356.4 minutes before analysis and setup.

Rational solves (294 cases per revision) and angles (168 per revision) account for 924 paired measurements. This identifies high-cost review candidates; it does not establish that those workloads are redundant. New-only APIs retain 149 current cases under the existing compatibility mitigation.

Proposed Changes

• Map each public operation and calling form to its timed contract, algorithm branch, const-generic specialization, input family, feature, dimension and correctness oracle.
• Identify genuinely equivalent/redundant timed coverage versus distinct behavior. Preserve construction-inclusive versus prepared costs where callers observe different work, and retain meaningful dense/sparse, conditioned/adversarial and exact/filter/fallback regimes.
• Keep the full existing benchmark catalog available for explicit diagnostics. Propose changes to the mandatory release selection only with an independently reviewed coverage argument; parameter combinations cannot be removed solely to meet a desired runtime.
• Preserve the README's existing LU factorization-plus-one-solve comparison through D=64 and its same-environment peer attribution. Small public functions remain legitimate benchmark targets; do not classify them as expendable merely because they are fast.
• Keep correctness/property/input tests comprehensive. Prefer removing justified orchestration or selection duplication before considering any sampling-policy change; blanket sample-count/warmup reductions are out of scope.
• Update independent catalogs, native filters, discovery/observed completeness checks and documentation together if the accepted policy changes. Preserve old evidence under its original plan identity.

Benefits

The release budget reflects deliberate scientific questions and distinct public workloads instead of an unchecked Cartesian product.

Implementation Notes and Acceptance

• Astra scientific checkpoint before any workload removal: review the coverage map, proposed exclusions and why each retained representative preserves the intended guarantee. Record disagreements and required evidence.
• Produce explicit required/optional/excluded cases with reasons; uncovered operations, features, important dimensions or algorithm regimes block acceptance.
• Keep Adopt shared benchmark workload availability across API revisions #320's new-API availability adoption compatible with the accepted policy; no historical absence or supported compile failure is treated as dispensable coverage.
• Verify native discovery against the independent inventory for both comparison revisions, and run the applicable correctness/native/consumer checks before future measurement.
• Document nominal versus observed cost separately. Do not claim an overall speedup without a comparable authorized end-to-end run.
• If no reduction is scientifically justified, record that result and the supported budget rather than weaken coverage to obtain a smaller count.

This is a consumer-owned scientific policy review, not a shared-tooling feature. It does not alter the running v0.5.2 experiment or retroactively reinterpret its results.

Workstream tracker and PR/dependency plan: #326.