mesh §3.2: the fidelity floor was checked against the route table, not the serve #183

Merged

dcharlot merged 2 commits from feat/mesh-fidelity-provenance into main 2026-10-10 09:56:29 -04:00

Conversation 0 Commits 2 Files changed 6 +362 -5

dcharlot commented 2026-10-07 14:38:31 -04:00

Owner

Copy link

A Mesh request carries two bounds, and only one of them was held to a standard
of honesty.

Energy has a provenance model whose coupling §3.3 requires be enforced before
sealing — in the spec's own words, "the rule that keeps 'measured' honest".
Fidelity had none.

The hole

serve computed fidelity_met at step 2, from route.chosen_fidelity —
which is ServingEngine::fidelity, documented as "the fidelity level this
engine is rated to deliver". The engine ran at step 3. The receipt was built
at step 4 from the step-2 value. Nothing the engine returned could change it.

So a backend admitted at F3 that degraded at serve time sealed
fidelity_met: 1 against an F3 floor, and the receipt looked ordinary.

The engine could not have been asked, either: ServeOutcome is counters only —
tokens in/out/accepted, cache hits, speculative proposals — with no fidelity
signal and no degradation signal. The figure could not have been anything but a
table lookup.

Two figures, two different claims

ServeOutcome gains delivered_fidelity: Option<Fidelity>, and fidelity_met
is derived from it when present.

figure	who says it	when
advertised — ServingEngine::fidelity	the route table	before the work; the basis the router admits on (§4)
delivered — ServeOutcome.delivered_fidelity	the backend that served	after the work

Both are sealed, as a pair, so a divergence between promise and delivery is
attributable to a named backend rather than merely surfacing as a failed floor.

Enforced, not just recorded

A backend reporting above its rating is refused
(MeshError::FidelityAboveRating), not clamped. It would be claiming a basis the
route decision never rested on, and clamping would hide a misconfigured or
dishonest engine behind a plausible receipt — the exact failure the field exists
to expose.

What this does not claim

Stated in the spec rather than implied: a delivered figure is still the backend's
own account. It is better grounded than a table entry written before the
work, and it is not an independent assessment of the output — Mesh does not score
responses. What the pair buys is that the divergence becomes visible.

An engine that reports nothing stays conformant and fidelity_met rests on the
advertisement. That is the older, weaker basis and the receipt says so by
carrying neither field, so a consumer requiring the stronger basis MUST check for
fidelity_delivered rather than reading fidelity_met alone.

Additive — and the drift check proved it twice

mesh/1 stays byte-stable. The two fields travel together or not at all:
carrying neither is exactly what a pre-existing receipt means, so the published
pack is unchanged.

The conformance drift check caught two earlier drafts of this change that were
not additive — first the reference engine reporting unconditionally, then
fidelity_advertised emitted on its own. ReferenceEngine therefore keeps the
historical shape by default, with reporting_delivered_fidelity() to exercise
the field; a real engine that can degrade needs no switch.

Spec

New §3.2.1 Advertised and delivered: the two figures, four MUSTs (derive from
delivered where present; never report above the rating; refuse rather than clamp;
carry the pair together or not at all), and the explicit limit on what a
delivered figure is worth. §5's ServeOutcome sketch and §6.1's wire table
updated.

Verification

mesh-rs workspace 57 passed, clippy clean.

reverted	caught by
fidelity_met back to the route table	a_backend_that_degrades_at_serve_time_does_not_meet_the_floor
a claim above the rating clamped instead of refused	a_backend_may_not_claim_a_level_above_the_one_it_was_admitted_on
the pair split — advertised emitted alone	the published-pack drift check
delivered emitted but left out of the signed core	a_reported_delivery_changes_the_signed_core_and_a_silent_one_does_not

🤖 Generated with Claude Code

A Mesh request carries two bounds, and only one of them was held to a standard of honesty. Energy has a provenance model whose coupling §3.3 requires be enforced before sealing — in the spec's own words, *"the rule that keeps 'measured' honest"*. Fidelity had none. ## The hole `serve` computed `fidelity_met` at **step 2**, from `route.chosen_fidelity` — which is `ServingEngine::fidelity`, documented as *"the fidelity level this engine is **rated** to deliver"*. The engine ran at step 3. The receipt was built at step 4 from the step-2 value. Nothing the engine returned could change it. So a backend admitted at `F3` that degraded at serve time sealed `fidelity_met: 1` against an `F3` floor, and the receipt looked ordinary. The engine could not have been asked, either: `ServeOutcome` is counters only — tokens in/out/accepted, cache hits, speculative proposals — with no fidelity signal and no degradation signal. The figure *could not* have been anything but a table lookup. ## Two figures, two different claims `ServeOutcome` gains `delivered_fidelity: Option<Fidelity>`, and `fidelity_met` is derived from it when present. | figure | who says it | when | |---|---|---| | **advertised** — `ServingEngine::fidelity` | the route table | before the work; the basis the router admits on (§4) | | **delivered** — `ServeOutcome.delivered_fidelity` | the backend that served | after the work | Both are sealed, **as a pair**, so a divergence between promise and delivery is attributable to a named backend rather than merely surfacing as a failed floor. ## Enforced, not just recorded A backend reporting **above** its rating is refused (`MeshError::FidelityAboveRating`), not clamped. It would be claiming a basis the route decision never rested on, and clamping would hide a misconfigured or dishonest engine behind a plausible receipt — the exact failure the field exists to expose. ## What this does not claim Stated in the spec rather than implied: a delivered figure is still the backend's **own account**. It is better grounded than a table entry written before the work, and it is not an independent assessment of the output — Mesh does not score responses. What the pair buys is that the divergence becomes *visible*. An engine that reports nothing stays conformant and `fidelity_met` rests on the advertisement. That is the older, weaker basis and the receipt says so by carrying neither field, so a consumer requiring the stronger basis MUST check for `fidelity_delivered` rather than reading `fidelity_met` alone. ## Additive — and the drift check proved it twice `mesh/1` stays byte-stable. The two fields travel together or not at all: carrying neither is exactly what a pre-existing receipt means, so the published pack is unchanged. The conformance drift check **caught two earlier drafts of this change that were not additive** — first the reference engine reporting unconditionally, then `fidelity_advertised` emitted on its own. `ReferenceEngine` therefore keeps the historical shape by default, with `reporting_delivered_fidelity()` to exercise the field; a real engine that can degrade needs no switch. ## Spec New **§3.2.1 Advertised and delivered**: the two figures, four MUSTs (derive from delivered where present; never report above the rating; refuse rather than clamp; carry the pair together or not at all), and the explicit limit on what a delivered figure is worth. §5's `ServeOutcome` sketch and §6.1's wire table updated. ## Verification `mesh-rs` workspace **57 passed**, clippy clean. | reverted | caught by | |---|---| | `fidelity_met` back to the route table | `a_backend_that_degrades_at_serve_time_does_not_meet_the_floor` | | a claim above the rating clamped instead of refused | `a_backend_may_not_claim_a_level_above_the_one_it_was_admitted_on` | | the pair split — advertised emitted alone | the **published-pack drift check** | | delivered emitted but left out of the signed core | `a_reported_delivery_changes_the_signed_core_and_a_silent_one_does_not` | 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-10-07 14:38:31 -04:00

mesh §3.2: the fidelity floor was checked against the route table, not the serve ... ca3190cd97

A Mesh request carries two bounds and only one of them was held to a standard of
honesty. Energy has a provenance model whose coupling §3.3 requires be enforced
before sealing — "the rule that keeps 'measured' honest". Fidelity had none.

`serve` computed `fidelity_met` at step 2, from `route.chosen_fidelity`, which is
`ServingEngine::fidelity` — documented as "the fidelity level this engine is
**rated** to deliver". The engine ran at step 3 and the receipt was built at step
4 from the step-2 value, so nothing the engine returned could change it. A
backend admitted at F3 that degraded at serve time sealed `fidelity_met: 1`
against an F3 floor, and the receipt looked ordinary.

The engine could not have been asked, either: `ServeOutcome` is counters only —
tokens in/out/accepted, cache hits, speculative proposals — with no fidelity
signal and no degradation signal. So the figure could not have been anything but
a table lookup.

`ServeOutcome` gains `delivered_fidelity: Option<Fidelity>`, and `fidelity_met`
is derived from it when present. Two figures, two different claims: the
advertisement is what the route table promised before the work and the basis the
router admitted the backend on; the delivered level is what the party that did
the work says it served. Both are sealed, as a pair, so a divergence is
attributable to a named backend rather than merely showing up as a failed floor.

Enforced, not just recorded: a backend reporting **above** its rating is refused
(`MeshError::FidelityAboveRating`) rather than clamped. It would be claiming a
basis the route decision never rested on, and clamping would hide a misconfigured
or dishonest engine behind a plausible receipt — the exact failure the field
exists to expose.

What this does not claim, stated in the spec rather than implied: a delivered
figure is still the backend's own account. It is better grounded than a table
entry written before the work and it is not an independent assessment of the
output — Mesh does not score responses. What the pair buys is that the divergence
becomes visible.

Additive, and `mesh/1` stays byte-stable. The two fields travel together or not
at all: their purpose is the comparison, and the advertisement alone adds nothing
a verifier lacks from `backend`. Carrying neither is exactly what a receipt
sealed before the fields existed means, so the published pack is unchanged — the
drift check proves it, and it caught two earlier drafts of this change that were
not additive (the reference engine reporting unconditionally, then
`fidelity_advertised` emitted on its own). `ReferenceEngine` therefore keeps the
historical shape by default, with `reporting_delivered_fidelity()` to exercise
the field; a real engine that can degrade needs no switch.

SPEC gains §3.2.1 with the four MUSTs, §5's `ServeOutcome` sketch and §6.1's
wire table updated.

mesh-rs workspace: 57 passed, clippy clean.

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

dcharlot force-pushed feat/mesh-fidelity-provenance from ca3190cd97 to 06a2017da8 2026-10-08 10:27:21 -04:00 Compare

dcharlot referenced this pull request from a commit 2026-10-08 11:40:25 -04:00

ci: a rebase ran every path-filtered workflow, because `paths:` matches the push delta

dcharlot referenced this pull request 2026-10-08 11:41:09 -04:00

ci: a rebase ran every path-filtered workflow, because paths: matches the push delta #191

dcharlot referenced this pull request from a commit 2026-10-08 14:36:23 -04:00

wai: a from-rest burst asserted a 2 ms race, and linux-arm64 called it

dcharlot referenced this pull request 2026-10-08 14:37:59 -04:00

wai: a from-rest burst asserted a 2 ms race, and linux-arm64 called it #192

dcharlot force-pushed feat/mesh-fidelity-provenance from 06a2017da8 to ce8a8b20a0 2026-10-09 02:53:26 -04:00 Compare

dcharlot added 1 commit 2026-10-09 08:51:33 -04:00

mesh: the gguf engine constructs ServeOutcome too, behind its own feature ... faf2d76f52

`standards workspaces build + test / mesh-rs` failed on this branch: adding
`delivered_fidelity` to `ServeOutcome` reached seven places in mesh, and I
updated five. The two I missed are both in `mesh-engine-gguf`, inside
`#[cfg(feature = "gguf")]`, so no default build on this machine compiles them
— only the matrix entry's `feature_tests: -p mesh-engine-gguf --features
gguf` does, which is why CI found it and local verification did not.

Both engines decode greedily from whatever model was loaded and form no
after-the-fact view of what they delivered, so they report `None`: the field's
documented historical shape, skipped on the wire, with `fidelity_met` falling
back to the advertised rating. That is exactly where these engines already
stood, so this is the absence-as-tag doing its job rather than a new claim.

Checked every other feature in the workspace for the same blind spot —
`mesh-core`/`mesh-meter --features hw-meter`, `mesh-openai --features server`,
`mesh-engine-gguf --features metal` and `--features rayon` — and `gguf` was
the only one broken. The workspace's tests pass, and so do the gguf feature
tests as CI runs them.

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

dcharlot merged commit 8f62e388e0 into main 2026-10-10 09:56:29 -04:00

dcharlot referenced this pull request from a commit 2026-10-10 09:56:31 -04:00

Merge pull request 'mesh §3.2: the fidelity floor was checked against the route table, not the serve' (#183) from feat/mesh-fidelity-provenance into main

dcharlot referenced this pull request from a commit 2026-10-10 10:01:52 -04:00

sandbox: a setup assertion walked a tree that still held the warm-up worker

dcharlot referenced this pull request from a commit 2026-10-14 01:40:12 -04:00

mesh: the identity rides the whole path, and the keys it adds are exactly two

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!183

No description provided.