Calibration Is the Product Surface, Not a Side Utility

Historical context: This article preserves the product model and examples described at its original publication date. The v0.13.0 transition replaced that operator workflow. Documentation links lead to maintained guidance; the retired commands and contracts below are not present-day instructions.

Thresholds, enablement gates, and resolved policy all make calibration part of the product boundary.

Highlights

• Threshold derivation: null sweeps emit tiers_patch_spectral_null.yaml with calibrated family_caps.* keys. See the null-sweeps note.
• Enablement discipline: variance equalization only turns on when paired Delta logNLL clears min_effect_lognll under the tier's sidedness rule. See the variance-enablement note.
• Policy continuity: patched keys surface as resolved_policy.* in later reports, giving the sweep -> patch -> policy -> report path a traceable identity. See the tier-policy note.

The linked articles describe different operator decisions: null sweeps propose thresholds, variance enablement constrains activation, and tier policy carries reviewed values into later reports. Their relationship is the subject of this overview.

Diagram

Historical calibration exposes three distinct decisions: derive threshold recommendations from null behavior, gate variance enablement with predictive paired evidence, and preserve reviewed policy values in later reports.

Three historical calibration responsibilities

Threshold derivation

Use clean no-op behavior to recommend spectral caps under a declared warning budget; retain the proposed tier patch.

Variance enablement

Use paired predictive evidence with sidedness and minimum-effect rules; retain the gate outcome and enablement provenance.

Policy continuity

Review proposed values and preserve the adopted settings in resolved_policy fields in later reports.

Separate responsibilities, not sequential proof of acceptance. This historical map introduces no new measured thresholds.

Here, “product surface” means the thresholds, enablement rules, reviewable patches, and resolved report fields an operator could inspect and govern.

1. Calibration Sets The Derivation Story

The first May post matters because it changes how threshold selection should be interpreted. The calibration CLI reference describes null sweeps as a workflow that measures clean no-op behavior and emits a patch-shaped recommendation. Threshold setting is no longer just taste plus experience. It becomes part of the formal operational story.

That is already product-surface behavior. A system whose thresholds are empirically derived and patchable exposes a different review interface than one whose thresholds live mostly in inherited defaults.

2. Calibration Sets The Enablement Story

The second May post adds a different kind of boundary. Variance equalization is not simply available because it exists in the implementation. On the public surface, it turns on only when predictive evidence clears tier-specific sidedness and minimum-effect rules.

That means calibration is not only about where thresholds come from. It is also about when a correction path may become active at all. The variance guard predictive gate is therefore a product-facing gate, not just an analysis note.

Again, that is not peripheral analysis. It is control over a live runtime behavior.

3. Calibration Sets The Policy Story

The third May post completes the path. Sweep outputs do not end in a human summary. They end in reviewable tiers_patch_*.yaml files that can be merged into runtime tier policy, then exposed later as resolved_policy.* in reports.

This is the clearest reason calibration belongs on the product surface. Its outputs survive. They do not disappear after an experiment review meeting. They become part of the policy that future evaluations inherit.

A system that exposes policy this way is telling you something important: calibration is part of how the product defines itself operationally.

Why This Framing Matters

Calling calibration a side utility encourages the wrong habits. It suggests that calibration can be deferred, hidden, or treated as a private research detail while the "real" product lives elsewhere.

The public InvarLock docs point in the opposite direction. The tier-policy catalog distinguishes calibrated values from explicit policy choices, and the guards reference makes resolved policy visible in the report surface. Calibration determines part of the threshold surface, part of the enablement surface, and part of the policy surface. That means it belongs inside serious operator review, release review, and evidence interpretation.

The same boundary points to the relevant evidence: threshold derivation, correction-path enablement, and the resolved policy recorded in reports.

What Calibration Still Does Not Solve

The conclusion remains narrow.

Calibration does not turn every decision into empiricism. The tier-policy catalog is explicit that some values are calibrated and others are policy choices. Calibration also does not eliminate the need for review, transfer checks, or recalibration when window budgets, hardware, or model families change. The tier v1 calibration note is still local to a specific published evidence surface.

So the useful conclusion is not "calibration solves the whole system." It is smaller and more useful: calibration is a real part of the system boundary that operators need to understand and govern.

Limitations

• Measurement claims are limited to the linked calibration notes.
• "Product surface" means the operator-visible threshold, gate, patch, and report set, narrower than "entire product" by design.
• Window-budget, hardware, and family-transfer questions still need their own evidence; calibration belongs on the product surface without implying that any specific calibrated value generalizes.

Sources

Website documentation explains the maintained workflow. The examples described here preserve the historical workflow at the article’s original publication date. These maintained guides explain the related concepts; they do not reinstate the retired commands or contracts.

• Optional diagnostics
• Schedule and policy
• Decision semantics
• Null Sweeps as Threshold Derivation, Not Tuning Folklore
• Variance Enablement Should Be Evidence-Gated
• From Sweep Outputs to Tier Policy