mesh: a cost model that gates must say where it was measured #92

Merged

dcharlot merged 1 commit from mesh/cost-calibration into main 2026-09-11 00:29:53 -04:00

Conversation 0 Commits 1 Files changed 1 +265 -5

dcharlot commented 2026-09-10 12:31:08 -04:00

Owner

Copy link

CostProfile feeds a joule ceiling, and it had no way to say what operating point its constants came from. Per-token energy is not a property of a backend; it is a property of a backend at an occupancy — fixed per-step overheads amortise across fuller batches and decode's memory traffic is shared, so the same weights on the same silicon cost materially less per token at saturation. Published figures are almost always the saturated ones.

At a ceiling, the direction of the error decides everything

• Over-estimating refuses work that would have fit. Visible, and it costs no joules — the operator sees a refusal and raises the budget.
• Under-estimating admits work the ceiling cannot cover. Silent, and the overspend is found after the joules are gone.

A saturation fit applied at low concurrency under-estimates. That is the unsafe direction, and nothing in the type could see it coming.

So the profile records the point it was measured at, and require_applicable_at refuses exactly the two cases that under-estimate — an undeclared calibration, and one applied below its measurement point — while permitting the case that over-estimates.

The asymmetry is the design. A guard refusing both directions would treat a conservative estimate as equally dangerous as an optimistic one, at a gate where only one of them can overspend. There is a test named for exactly that.

This ships no constants

Calibration.source names the measurement rather than substituting for it — a harness run id, a receipt content-id, anything that resolves to the actual observation. Importing a published coefficient would put an unfalsified number inside a gate, and the only energy-calibration harness in this tree measures Apple silicon, so there is no honest cross-vendor figure to ship. The numbers stay the operator's to measure — the same reason CostProfile shipped no default profile and BandingScale ships no canonical scale.

Two deliberate limits, stated rather than papered over

The type records provenance and does not correct the estimate: scaling a fit across occupancy needs a law this tree has not measured, and inventing one would be the same failure in a new place. A test pins that adding provenance moves no estimate.

It also adds no memory-traffic term. The concurrency dependence is where the gate is actually exposed; a second unmeasured coefficient would not help.

One API break

CostProfile loses Copy — an owned provenance string cannot be Copy. The alternative, a &'static str, would have locked out exactly the operators who load profiles from configuration. Every dependent is in-workspace (checked, not assumed) and the workspace compiles unchanged.

calibration is Option, and wire() appends only when declared, so a profile without one seals byte-identically to every receipt written before this field existed.

Verification

20 test binaries green, 6 new. Includes a test that the existing saturating arithmetic still cannot wrap — a wrapped estimate would come back small, which is the admitting direction.

🤖 Generated with Claude Code

`CostProfile` feeds a joule ceiling, and it had no way to say what operating point its constants came from. Per-token energy is not a property of a backend; it is a property of a backend **at an occupancy** — fixed per-step overheads amortise across fuller batches and decode's memory traffic is shared, so the same weights on the same silicon cost materially less per token at saturation. Published figures are almost always the saturated ones. ## At a ceiling, the direction of the error decides everything - **Over-estimating refuses** work that would have fit. Visible, and it costs no joules — the operator sees a refusal and raises the budget. - **Under-estimating admits** work the ceiling cannot cover. Silent, and the overspend is found after the joules are gone. A saturation fit applied at low concurrency under-estimates. That is the unsafe direction, and nothing in the type could see it coming. So the profile records the point it was measured at, and `require_applicable_at` refuses exactly the two cases that under-estimate — an undeclared calibration, and one applied *below* its measurement point — while **permitting** the case that over-estimates. **The asymmetry is the design.** A guard refusing both directions would treat a conservative estimate as equally dangerous as an optimistic one, at a gate where only one of them can overspend. There is a test named for exactly that. ## This ships no constants `Calibration.source` names the measurement rather than substituting for it — a harness run id, a receipt content-id, anything that resolves to the actual observation. Importing a published coefficient would put an unfalsified number inside a gate, and the only energy-calibration harness in this tree measures Apple silicon, so there is no honest cross-vendor figure to ship. The numbers stay the operator's to measure — the same reason `CostProfile` shipped no default profile and `BandingScale` ships no canonical scale. ## Two deliberate limits, stated rather than papered over The type records provenance and does **not** correct the estimate: scaling a fit across occupancy needs a law this tree has not measured, and inventing one would be the same failure in a new place. A test pins that adding provenance moves no estimate. It also adds **no memory-traffic term**. The concurrency dependence is where the gate is actually exposed; a second unmeasured coefficient would not help. ## One API break `CostProfile` loses `Copy` — an owned provenance string cannot be `Copy`. The alternative, a `&'static str`, would have locked out exactly the operators who load profiles from configuration. Every dependent is in-workspace (checked, not assumed) and the workspace compiles unchanged. `calibration` is `Option`, and `wire()` appends only when declared, so a profile without one seals byte-identically to every receipt written before this field existed. ## Verification 20 test binaries green, 6 new. Includes a test that the existing saturating arithmetic still cannot wrap — a wrapped estimate would come back small, which is the admitting direction. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-09-10 12:31:08 -04:00

mesh: a cost model that gates must say where it was measured ... 18cad976f7

`CostProfile` feeds a joule ceiling, and it had no way to say what operating
point its constants came from. Per-token energy is not a property of a backend;
it is a property of a backend **at an occupancy** — fixed per-step overheads
amortise across fuller batches and decode's memory traffic is shared, so the
same weights on the same silicon cost materially less per token at saturation.
Published figures are almost always the saturated ones, because that is the
number worth quoting.

At a ceiling the direction of that error decides everything:

- **Over-estimating refuses** work that would have fit. Visible, and it costs no
  joules — the operator sees a refusal and raises the budget.
- **Under-estimating admits** work the ceiling cannot cover. Silent, and the
  overspend is found after the joules are spent.

A saturation fit applied at low concurrency under-estimates. That is the unsafe
direction, and nothing in the type could see it coming.

So the profile records the point it was measured at, and `require_applicable_at`
refuses exactly the two cases that under-estimate — an undeclared calibration,
and one applied below its measurement point — while **permitting** the case that
over-estimates. The asymmetry is the design. A guard refusing both directions
would treat a conservative estimate as equally dangerous as an optimistic one at
a gate where only one of them can overspend.

`Calibration.source` names the measurement rather than substituting for it: a
harness run id, a receipt content-id, anything that resolves to the actual
observation. **This ships no constants.** Importing a published coefficient
would put an unfalsified number inside a gate, and the only energy-calibration
harness in this tree measures Apple silicon, so there is no honest cross-vendor
figure to ship. The numbers stay the operator's to measure — the same reason
`CostProfile` shipped no default profile and `BandingScale` ships no canonical
scale.

Two deliberate limits, stated rather than papered over. The type records
provenance and does **not** correct the estimate: scaling a fit across occupancy
needs a law this tree has not measured, and inventing one would be the same
failure in a new place. And this adds no memory-traffic term — the concurrency
dependence is where the gate is actually exposed, and a second unmeasured
coefficient would not help.

`CostProfile` loses `Copy` (an owned provenance string cannot be `Copy`). The
alternative, a `&'static str`, would have locked out exactly the operators who
load profiles from configuration. Every dependent is in-workspace — checked, not
assumed — and the workspace compiles unchanged.

`calibration` is `Option`, and `wire()` appends only when it is declared, so a
profile without one seals byte-identically to every receipt written before this
field existed.

Verified: 20 test binaries green, 6 new. A test pins that adding provenance
moves no estimate, and another that the existing saturating arithmetic still
cannot wrap.

Co-Authored-By: Claude Opus 5 <[email protected]>

dcharlot merged commit f21ae74a67 into main 2026-09-11 00:29:53 -04:00

dcharlot referenced this pull request from a commit 2026-09-11 00:29:55 -04:00

mesh: a cost model that gates must say where it was measured (#92)

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!92

No description provided.