Summary
Follow-up hardening identified during the final independent review of PR #116.
The canonical CV benchmark source currently records a top-level protocol.dtype field such as "float64". In the CV runner this reflects the benchmark input/source dtype, but some estimators can intentionally use a different internal working dtype. In particular, LogisticRegressionCV(gpu_cv_mixed_precision=True) converts the GPU CV working design to float32 while the source still records protocol.dtype = "float64".
This is not a correctness problem in PR #116: the focused physical evidence explicitly records mixed-precision float32 and float64 cases, and the canonical source is truthful about the generated input dtype. However, the current field name can be misread as the estimator's actual working precision.
Proposed scope
- Clarify the schema semantics of
protocol.dtype, preferably by renaming/documenting it as an input dtype (for example input_dtype), or add explicit working-dtype metadata where relevant.
- Preserve backward compatibility/migration for existing immutable benchmark sources.
- Update parser/schema/docs/tests and generated frontend data consistently.
- For mixed-precision CV, make it possible to distinguish input dtype from internal CV working dtype without rewriting historical evidence.
Acceptance
- Existing historical benchmark sources remain immutable/auditable.
- New sources have unambiguous dtype provenance.
- Schema/parser/frontend tests cover mixed input/working precision.
Related: PR #116. This is LOW-severity benchmark/provenance hardening and does not block PR #116.
Summary
Follow-up hardening identified during the final independent review of PR #116.
The canonical CV benchmark source currently records a top-level
protocol.dtypefield such as"float64". In the CV runner this reflects the benchmark input/source dtype, but some estimators can intentionally use a different internal working dtype. In particular,LogisticRegressionCV(gpu_cv_mixed_precision=True)converts the GPU CV working design tofloat32while the source still recordsprotocol.dtype = "float64".This is not a correctness problem in PR #116: the focused physical evidence explicitly records mixed-precision float32 and float64 cases, and the canonical source is truthful about the generated input dtype. However, the current field name can be misread as the estimator's actual working precision.
Proposed scope
protocol.dtype, preferably by renaming/documenting it as an input dtype (for exampleinput_dtype), or add explicit working-dtype metadata where relevant.Acceptance
Related: PR #116. This is LOW-severity benchmark/provenance hardening and does not block PR #116.