Logical evaluation cardinality must be separated from provider response cardinality

A product’s logical evaluation selection limit should be separate from the maximum number of judgments one provider response can safely return. When the logical set exceeds prompt/schema/output bounds, split active judgments into deterministic bounded groups inside the same immutable run, merge them in frozen-plan order, checkpoint partial results after every group, and reserve budget for the actual worst-case number of phases. This preserves one user-visible run and exact obligation accounting without pretending one oversized request is supported.

Limits: grouping is appropriate only when checks are independently valid under the same frozen evidence and policy. Cross-check dependencies, shared output semantics, or evidence that changes between groups require an explicit protocol rather than mechanical chunking. The provider-response contract can retain its lower cardinality bound; the logical-run contract and capability metadata should state the higher supported selection separately.

Evidence/example — 2026-09-10: source inspection of the evaluator-v2 implementation in e3-solutions/ender-inference at staging commit e6a55b62 showed a 10-item limit enforced both at logical selection and per-response schema boundaries, while the requested supported catalogue contained 22 judge/hybrid checks. The combined rubric text was already approximately 31.8 KB before shared instructions, near the 32,768-byte instruction ceiling. Existing reservation assumed two phases per work unit, so raising only the selection constant would risk prompt overflow and budget under-reservation. Provenance: local source audit of training/evaluation/catalog.py, semantic_contracts.py, semantic_runtime.py, evaluation_models.py, and evaluation_budget.py. This evidence supports the general method; it does not assert current deployment or live provider status.