open-standards/mesh
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Transaction Science 5208dc5936
All checks were successful
no-vanity-metrics / Scan committed Markdown for vanity metrics (pull_request) Successful in 3s
no-vanity-metrics / WAI public text names no comparison (pull_request) Successful in 3s
no-vanity-metrics / WAI public text names no company or product (pull_request) Successful in 3s
standards workspaces build + test / eoc-rs (pull_request) Successful in 1m57s
standards workspaces build + test / jcp-rs (pull_request) Successful in 1m29s
standards workspaces build + test / proof-rs (pull_request) Successful in 1m16s
standards workspaces build + test / sandbox-rs (pull_request) Successful in 2m13s
standards workspaces build + test / smart-byte-rs (pull_request) Successful in 3m43s
standards workspaces build + test / jouleclaw-rs (pull_request) Successful in 8m28s
standards workspaces build + test / aac-rs (pull_request) Successful in 3m42s
standards workspaces build + test / joule-code-rs (pull_request) Successful in 3m18s
standards workspaces build + test / joulecontract-rs (pull_request) Successful in 1m20s
standards workspaces build + test / map-rs (pull_request) Successful in 1m56s
standards workspaces build + test / mesh-rs (pull_request) Successful in 1m6s
standards workspaces build + test / openpay (pull_request) Successful in 7m12s
standards workspaces build + test / arl-rs (pull_request) Successful in 3m41s
standards workspaces build + test / joule-ui-rs (pull_request) Successful in 5m16s
standards workspaces build + test / jouledesk-rs (pull_request) Successful in 4m18s
standards workspaces build + test / joulehook-rs (pull_request) Successful in 7m16s
standards workspaces build + test / sense-rs (pull_request) Successful in 4m7s
standards workspaces build + test / macOS energy backends (pull_request) Successful in 5m30s
mesh: withdraw the GPU per-decision figure — another process held 99.5% of the GPU
I reported 0.104 J per three-question decision as GPU 0.0966 J plus process CPU
0.0075 J, and put it in SPEC §3.6's worked example. The GPU half does not hold.

`gpu_share.py` measures the thing I had assumed away: per-process GPU time from
`accumulatedGPUTime` on each IOUserClient in the IOAccelerator subtree, as a
**delta over the span** rather than the cumulative totals (which are useless —
WindowServer has days of accrued time). Over a 4.06 s span with an MLX matmul
loop running, **com.apple.Safari held 2.470 s of 2.482 s — 99.5%** — while this
process registered 0.000 s. The host was at load average 132 on 18 CPUs,
running another session's VVC/VTM encodes, which is this machine's normal state
rather than an unlucky moment.

A rail delta over that span is a reading of Safari. The rule already shipped
elsewhere in the fleet is the right one: attribute a rail reading to this
process only when it holds ≥99% of the GPU time advancing in the span, report
exactly zero when it holds none, and otherwise **issue no GPU figure**, marking
the span CPU-only and partial. By that rule this measurement issues none.

The 0.08% idle-bracket correction I cited as evidence of cleanliness proves
nothing, and I should not have read it that way: a bracket subtracts *steady*
background, and cannot subtract a contending process whose work overlaps the
span but not the brackets.

What stands, and why it is the more interesting half: the **CPU** figures are
untouched — Laya 0.486 J and GLiNER2.5-Decide 0.555 J per three-question
decision — because the kernel's per-process counter attributes to a principal,
so neither load average 132 nor Safari's GPU work enters them. That is exactly
what `Attribution::Process` is for, and it took a contaminated GPU figure to
demonstrate it. SPEC §3.6's worked example now uses the CPU figure (486 000 µJ,
162 mJ per answered question) and says why it is not the GPU one. Latency
figures are unaffected.

Also corrects the direction of my earlier framing. I presented the GPU path as
"4.7× cheaper, and the price is that it cannot be bound to a principal". The
truth is stronger: on a shared host it cannot be bound to a principal *and*
the number itself is not the workload's. A sound GPU figure needs a host with
no display server and no other GPU client — on this fleet, a headless Linux box
with NVML, not a Mac.

`gpu_rail_period.py` is also added, the harness behind 92449670's correction of
the rail's declared period.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-10-05 07:20:58 -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: withdraw the GPU per-decision figure — another process held 99.5% of the GPU 2026-10-05 07:20:58 -04:00
tools/joules-per-decision mesh: withdraw the GPU per-decision figure — another process held 99.5% of the GPU 2026-10-05 07:20:58 -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 jouleclaw-energy: a live IOReport reading is a hardware reading, and only a live one 2026-09-30 20:17:13 -04:00
SPEC.md mesh: a typed decision is a unit of work this spec could not measure 2026-10-05 07:20:58 -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, where
# the counter is live; a counter that is not live falls back to the estimator)
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.