Define the quality boundary before reducing the state

A single aggregate score can hide offsetting failures. Average performance may remain stable while a critical capability, subgroup, sequence regime or safety behaviour degrades. The relevant boundary can therefore require several measurements and hard invariants.

The dimensions depend on the system: task accuracy, calibration, generation quality, retrieval behaviour, long-context stability, latency constraints, refusal behaviour or domain-specific error costs. The boundary should reflect the intelligence the deployment actually requires.

If metrics and tolerances are chosen after candidate results are visible, the evaluation can be shaped around the candidate that already looks best. Pre-declaration does not eliminate scientific judgement, but it makes changes to that judgement visible.

A practical boundary identifies the evaluation set, workload distribution, metrics, aggregation rules, tolerances, critical invariants and conditions that trigger rejection. Any later revision should create a new version of the claim.

• Capabilities and behaviours in scope
• Datasets or evaluation populations
• Metrics and aggregation rules
• Permitted tolerances
• Hard rejection conditions
• Workload and runtime coverage

Zero quality loss is not a claim of metaphysical identity between two systems. It is a strict acceptance rule relative to a defined and disclosed boundary: the candidate must not cross that boundary on the evidence reserved to judge it.

The boundary may contain confidence intervals, equivalence margins or exact invariants depending on the target. Whatever form it takes, a public result must state it. Without that definition, “no loss” cannot be examined or reproduced.

Zero quality loss is a rule for accepting reductions—not permission to leave quality undefined.

A candidate can appear valid when tested on inputs that are easier, shorter or otherwise different from the operating distribution. Memory and quality can both change with sequence length, batch size, modality, routing pattern and concurrency.

Validation should therefore represent the declared workload and expose important slices. When coverage is limited, the result should be limited with it rather than generalized to the entire architecture.

A future controlled runtime layer would need more than a one-time certificate. Changes in workloads, software, hardware or model behaviour could alter the conditions under which a state remains valid.

The long-term objective is a bounded operating system: validated states, monitored conditions, explicit rollback rules and renewed evidence whenever the boundary changes. That is a future application direction, not a claim of current operation.