open-standards/mesh
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Transaction Science 29eb46469e
All checks were successful
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 9s
standards workspaces build + test / macOS energy backends (pull_request) Has been skipped
repository checks / lockfiles, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 56s
standards workspaces build + test / joulehook-rs (joulehook/joulehook-rs, joulehook-rs, linux) (pull_request) Successful in 1m20s
standards workspaces build + test / mesh-rs (mesh/mesh-rs, -p mesh-engine-gguf -p mesh-openai --features mesh-engine-gguf/gguf,mesh-openai/server, mesh-rs, linux-arm64) (pull_request) Successful in 2m45s
mesh-core: one steward per journal — the chain detects a second, it cannot stop one
§2.2 requires a steward that can restart to keep a durable journal and to
re-establish spend by replaying it. Nothing required the journal to have one
writer, and `FileJournal::open` was

    OpenOptions::new().read(true).append(true).create(true)

with no lock at all.

Mesh's journal is hash-chained (`{seq, prev}`), and that changes the failure
from jcp-wire's without removing it. **The chain detects a second writer; it
does not prevent one.** Two stewards sharing a journal each replay it, each
re-establish the same spend and each serve against it, so the grant is
overspent *while both are running*. Their records then collide on `seq`, the
chain no longer forms, and `Mesh::with_journal` refuses the journal entirely —
so the detection arrives after the overspend and costs the steward its ability
to restart. `open` also truncates a torn trailing line, so a concurrent opener
can cut the file out from under an appender.

`open` now takes an exclusive lock, **before** the read and the truncation: an
opener refused afterwards would already have cut the holder's file.

The lock is `std::fs::File::try_lock`, stable since Rust 1.89 — no `unsafe`,
which this workspace denies, no new dependency, no lockfile change in any
workspace, and no platform caveat, because std covers Windows as well as unix.
Verified on the toolchain rather than assumed: a second `try_lock` on a held
file returns `WouldBlock`, and the lock releases when the file is dropped. It
is also released when the process dies, so a crash leaves no stale lock to
recover, which a lock-file sidecar would need a story for.

Where a platform cannot lock at all, `open` **fails** rather than proceeding:
serving against a record another steward may also be writing is the overspend
this exists to stop.

Falsification, five mutations, all killed by their named test. **M5 survived the
first round** — swallowing the unsupported-platform error broke nothing, because
that arm is unreachable on a platform whose locks work, and an unreachable arm
is exactly where a fail-open hides. `lock_outcome` is therefore split out from
the I/O so every arm is reachable from a test, and M5 now fails only its own.
This is the third fix running where the untested thing was the central claim.

M2 is the other one worth reading: the lock still present but taken after the
truncation fails **only** the no-truncation test, isolating the ordering from
the existence of the lock.

§2.2 gains the requirement, since the gap was in the spec before it was in the
code. `jcp-wire` carried the identical defect and is fixed the same way in
#346; the two standards deliberately keep their own copies of this machinery,
as `mesh-receipt` already vendors JCR-1 rather than depending on `jcp-schema`.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-10-19 22:04:14 -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-core: one steward per journal — the chain detects a second, it cannot stop one 2026-10-19 22:04:14 -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 mesh: a grant is spent only by its issuer, at the steward it names, and its spend survives a restart 2026-10-17 17:13:42 -04:00
SPEC.md mesh-core: one steward per journal — the chain detects a second, it cannot stop one 2026-10-19 22:04:14 -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 ──▶ route (cheapest-sufficient) ──▶ authorise (JCP grant)
                                                     │
                                                     ▼
                     meter + debit ◀── serve (engine) ──▶ tokens
                                                     │
                                                     ▼
                         sealed JCR-1 receipt: µJ / accepted token

Four roles — caller, router, engine, steward — and four phases per serve: route, authorise, meter, seal. The grant is decided by JCP's own runtime before any work runs, so its expiry, caveats and remaining budget bind here as at any JCP enforcement point, and the metered joules are debited against it afterwards. A grant is spent only by its issuer, who signs each presentation for one request, and only at the steward it was issued to; each decision is journalled before the work, so a restart gives no budget back. 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, and ProcessMeter: this process's own CPU and GPU energy for an engine that runs in process, measured when a span covers the whole request
mesh-receipt the mesh/1 receipt, JCR-1 sealing (det-CBOR + COSE_Sign1), and a hash-chained log
mesh-core the orchestration that ties route → authorise → 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.