open-standards/mesh
Repository files (latest commit first)
Filename Latest commit message Latest commit date
David Charlot 18cad976f7
All checks were successful
standards workspaces build + test / aac-rs (pull_request) Successful in 32s
standards workspaces build + test / joule-code-rs (pull_request) Successful in 37s
standards workspaces build + test / jouleclaw-rs (pull_request) Successful in 2m13s
standards workspaces build + test / joulecontract-rs (pull_request) Successful in 33s
standards workspaces build + test / map-rs (pull_request) Successful in 31s
standards workspaces build + test / mesh-rs (pull_request) Successful in 27s
standards workspaces build + test / openpay (pull_request) Successful in 1m17s
standards workspaces build + test / eoc-rs (pull_request) Successful in 1m47s
standards workspaces build + test / jcp-rs (pull_request) Successful in 1m14s
standards workspaces build + test / proof-rs (pull_request) Successful in 1m15s
standards workspaces build + test / sandbox-rs (pull_request) Successful in 2m0s
standards workspaces build + test / smart-byte-rs (pull_request) Successful in 2m32s
standards workspaces build + test / arl-rs (pull_request) Successful in 9m28s
standards workspaces build + test / joule-ui-rs (pull_request) Successful in 10m17s
standards workspaces build + test / jouledesk-rs (pull_request) Successful in 10m22s
standards workspaces build + test / joulehook-rs (pull_request) Successful in 9m31s
standards workspaces build + test / sense-rs (pull_request) Successful in 10m41s
mesh: a cost model that gates must say where it was measured
`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]>
2026-09-10 12:30:48 -04:00
..
conformance/v1 wai.generate.spectral: extend the lexicon to 370 words (data-only, pin unchanged) 2026-06-27 05:33:47 -04:00
mesh-rs mesh: a cost model that gates must say where it was measured 2026-09-10 12:30:48 -04:00
CONTRIBUTING.md wai.generate.spectral: extend the lexicon to 370 words (data-only, pin unchanged) 2026-06-27 05:33:47 -04:00
LICENSE wai.generate.spectral: extend the lexicon to 370 words (data-only, pin unchanged) 2026-06-27 05:33:47 -04:00
LICENSE-SPEC wai.generate.spectral: extend the lexicon to 370 words (data-only, pin unchanged) 2026-06-27 05:33:47 -04:00
README.md wai.generate.spectral: extend the lexicon to 370 words (data-only, pin unchanged) 2026-06-27 05:33:47 -04:00
SPEC.md wai.generate.spectral: extend the lexicon to 370 words (data-only, pin unchanged) 2026-06-27 05:33:47 -04:00

Mesh

Energy-accounted inference serving & routing. One of the Transaction Science open standards.

Mesh treats every inference as a metered transaction. A request declares a joule ceiling and a fidelity floor; the mesh routes it to the cheapest-sufficient model on the cheapest-sufficient backend, serves it under an energy meter, and seals a receipt whose headline figure is microjoules per accepted output token — measured at the meter, not estimated from a price list.

The serving shelf reports dollars per token and tokens per second. Mesh reports the number that is physical, comparable across hardware, and impossible to inflate: the joule.

The shape

ServeRequest ──▶ authorise (JCP grant) ──▶ route (cheapest-sufficient)
                                              │
                                              ▼
                          meter ◀── serve (engine) ──▶ tokens
                                              │
                                              ▼
                         sealed JCR-1 receipt: µJ / accepted token

Four roles — caller, router, engine, steward — and four phases per serve: authorise, route, meter, seal. See SPEC.md §2.

The reference workspace

mesh-rs/ is a pure-Rust reference implementation:

Crate What it is
mesh-schema wire types — ServeRequest, Fidelity, two-part Energy, RouteDecision, ServeOutcome
mesh-router energy-weighted cheapest-sufficient routing with a full candidate audit
mesh-engine the ServingEngine interface + a deterministic, weights-free ReferenceEngine
mesh-engine-gguf a real backend (behind gguf): wraps the family's pure-Rust GGUF/Metal inference substrate so the mesh routes and meters actual model tokens
mesh-meter the meter window; an always-available estimator + an optional bridge to the family hardware meter (RAPL / NVML / Apple) behind hw-meter
mesh-receipt the mesh/1 receipt, JCR-1 sealing (det-CBOR + COSE_Sign1), and a hash-chained log
mesh-core the orchestration that ties authorise → route → meter → seal together
mesh-conformance the deterministic reference scenario, its checks, and the gen-vectors bin

Mesh rides on JCP (a serve request is authorised by a JCP grant; receipts seal in JCR-1), dispatches to runtimes such as JouleClaw, and routes across compute described by EOC and isolated by Sandbox. It introduces no new cryptography (see SPEC.md §9).

Run it

cd mesh-rs

# all crates green
cargo test --workspace
cargo clippy --workspace --all-targets

# end-to-end: mint a JCP grant, serve, print the sealed receipt
cargo run -p mesh-core --example demo

# on Linux/RAPL or a CUDA/NVML box, meter real silicon (HwShunt provenance)
cargo run -p mesh-core --example demo --features hw-meter-rapl

# regenerate the published conformance vectors
cargo run -p mesh-conformance --bin gen-vectors -- ../conformance/v1

# serve a REAL model end-to-end through Mesh (Falcon-H1 0.5B), seal the receipt
cargo run --release -p mesh-engine-gguf --features gguf --bin serve_falcon -- \
    /path/to/falcon-h1-0.5b-instruct 12 "The capital of France is"

The serve_falcon run demonstrates the whole standard on real model tokens: a JCP grant authorises each request (an underfunded grant is refused before any decode runs), the cheapest-sufficient backend is chosen, the decode is metered, and a mesh/1 receipt is sealed and hash-chained across the session — e.g. prompt "The capital of France is" → " Paris. It is known for its historical landmarks", prompt "Photosynthesis is the process by which" → " plants convert sunlight into chemical energy in the form of", with both seals verifying and the chain's prev-links intact.

The demo prints the route (every backend weighed, with the reason each was kept or rejected), the honest energy provenance, and the wedge metric — then verifies the sealed envelope under the steward key.

Status

v0.1.0-draft.1. Reference workspace builds and tests green (mesh-schema, mesh-router, mesh-engine, mesh-meter, mesh-receipt, mesh-core, mesh-conformance); cargo clippy --all-targets warning-free; published vectors in conformance/v1/. The reference engine is deterministic and weights-free; production backends implement the same ServingEngine interface — mesh-engine-gguf (behind gguf) is a real one over the family's pure-Rust GGUF/Metal substrate, kept out of the default build so it needs no weights.