mesh: the real engines address their weights, so a grant's ModelIn can admit them and a receipt binds what answered #311

Merged
dcharlot merged 1 commit from feat/mesh-engine-weights-digest into main 2026-10-18 07:19:40 -04:00
Owner

The gap

The real engines in mesh-engine-gguf (Gemma and Falcon-H1) reported no weights_digest and no precision. Two things followed:

  • Receipts were weak. A receipt from a real model bound it by recipe name alone, the weaker basis SPEC §3.6 describes.
  • ModelIn couldn't match. #294 routes on the model a backend names, so a grant whose ModelIn caveat named its permitted model refused every real backend. A real backend names no model.

The engine's own comment recorded the intended fix: address the weights once, at load, over every byte, and report nothing rather than a partial digest.

The fix

  • mesh_engine::weights_digest(dir, files) is the shared rule (SPEC §3.6). It is BLAKE3 over the canonical list of the files the forward pass reads, in path order. Each file is named by its path relative to the model directory and addressed by the streamed BLAKE3 of all its bytes. File names are part of the address; listing order is not.
  • GgufEngine addresses config.json plus model.safetensors, or the index plus every shard it names. A named shard missing from disk is an error, not a smaller address. It reports fp32: the loader widens every tensor to f32.
  • FalconEngine addresses config.json plus model.safetensors. The tokenizer is not addressed: it maps text to the ids a caller sends and never reaches the forward pass. It reports bf16, the only dtype it binds.
  • Same digest before and after: both engines report the digest before serving (ServingEngine::weights_digest) and the same digest in the outcome, which mesh-core's model check requires.

Checked

On the build host:

  • mesh-rs: 79 tests pass. The synthetic model-directory test in mesh-engine-gguf runs under the gguf feature, which CI's mesh-rs leg builds.
  • Real weights: a sharded 12B Gemma directory (config, index and three shards) addresses exactly the files on disk. It took 8.5 minutes from the host's external disk. At load the loader has just read those same bytes, so they normally come from the page cache.
  • Lockfiles: every Cargo.lock is current (--locked), including joulehook-rs, which locks mesh-engine.
  • Clippy is clean on both crates.
  • Mutations: each fails tests:
    • names left out of the manifest
    • hashing only a file's head
    • skipping the index's shards
  • Repository checks: spec references, tests-in-CI, vanity metrics and orphan sources all pass locally.

🤖 Generated with Claude Code

## The gap The real engines in `mesh-engine-gguf` (Gemma and Falcon-H1) reported no `weights_digest` and no `precision`. Two things followed: - **Receipts were weak.** A receipt from a real model bound it by recipe name alone, the weaker basis SPEC §3.6 describes. - **`ModelIn` couldn't match.** #294 routes on the model a backend names, so a grant whose `ModelIn` caveat named its permitted model refused every real backend. A real backend names no model. The engine's own comment recorded the intended fix: address the weights once, at load, over every byte, and report nothing rather than a partial digest. ## The fix - **`mesh_engine::weights_digest(dir, files)`** is the shared rule (SPEC §3.6). It is BLAKE3 over the canonical list of the files the forward pass reads, in path order. Each file is named by its path relative to the model directory and addressed by the streamed BLAKE3 of all its bytes. File names are part of the address; listing order is not. - **`GgufEngine`** addresses `config.json` plus `model.safetensors`, or the index plus every shard it names. A named shard missing from disk is an error, not a smaller address. It reports `fp32`: the loader widens every tensor to f32. - **`FalconEngine`** addresses `config.json` plus `model.safetensors`. The tokenizer is not addressed: it maps text to the ids a caller sends and never reaches the forward pass. It reports `bf16`, the only dtype it binds. - **Same digest before and after:** both engines report the digest before serving (`ServingEngine::weights_digest`) and the same digest in the outcome, which mesh-core's model check requires. ## Checked On the build host: - **mesh-rs:** 79 tests pass. The synthetic model-directory test in mesh-engine-gguf runs under the `gguf` feature, which CI's mesh-rs leg builds. - **Real weights:** a sharded 12B Gemma directory (config, index and three shards) addresses exactly the files on disk. It took 8.5 minutes from the host's external disk. At load the loader has just read those same bytes, so they normally come from the page cache. - **Lockfiles:** every `Cargo.lock` is current (`--locked`), including joulehook-rs, which locks mesh-engine. - **Clippy** is clean on both crates. - **Mutations:** each fails tests: - names left out of the manifest - hashing only a file's head - skipping the index's shards - **Repository checks:** spec references, tests-in-CI, vanity metrics and orphan sources all pass locally. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
mesh: the real engines address their weights, so a grant's ModelIn can admit them and a receipt binds what answered
All checks were successful
repository checks / lockfiles, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 1m58s
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 19s
standards workspaces build + test / macOS energy backends (pull_request) Has been skipped
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 56s
standards workspaces build + test / joulehook-rs (joulehook/joulehook-rs, joulehook-rs, linux) (pull_request) Successful in 1m15s
08b5db2c23
The GGUF-crate engines (Gemma and Falcon-H1) reported no `weights_digest`
and no `precision`. A receipt from a real model therefore bound it by
recipe name alone, and #294's routing gave a grant's `ModelIn` caveat
nothing to match. A grant that named the model it permitted refused every
real backend. The engine itself recorded the intended fix: address the
weights once, at load, over every byte, and report nothing rather than a
partial digest.

- `mesh_engine::weights_digest(dir, files)` is the shared rule (SPEC §3.6).
  It is BLAKE3 over the canonical list of the files the forward pass reads.
  Each file is named by its path relative to the model directory and
  addressed by the streamed BLAKE3 of all its bytes, in path order. File
  names are part of the address, and listing order is not.
- `GgufEngine` addresses `config.json` plus `model.safetensors`, or the
  index plus every shard it names. A shard the index names but the
  directory lacks is an error. It reports `fp32`: the loader widens every
  tensor to f32.
- `FalconEngine` addresses `config.json` plus `model.safetensors`. The
  tokenizer is not addressed, because it maps text to the ids a caller
  sends and does not reach the forward pass. It reports `bf16`, the only
  dtype it binds.
- Both report the digest before serving (`ServingEngine::weights_digest`)
  and the same digest after, which is what mesh-core's model check
  requires.
- SPEC §3.6 states the rule.

Checked on the build host:
- mesh-rs: 79 tests pass. mesh-engine-gguf's synthetic-directory test
  runs under the gguf feature, as CI's mesh-rs leg builds it.
- On real weights, a sharded 12B Gemma directory (config, index and three
  shards) addresses exactly the files on disk. It took 8.5 minutes from
  the host's external disk; at load the loader has just read the same
  bytes, so they normally come from the page cache.
- Every Cargo.lock is current, including joulehook-rs, which locks
  mesh-engine. Clippy is clean.
- Mutations each fail tests: names left out of the manifest, hashing only
  a file's head, and skipping the index's shards.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
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!311
No description provided.