mesh/1: a signed weights change record, and a gate that holds a backend to it #382

Merged

dcharlot merged 1 commit from feat/mesh-weights-change-record into main

2026-10-21 07:29:47 -04:00

dcharlot commented

2026-10-21 05:19:14 -04:00

Owner

Sweep 2026-10-19 item #6, second part. A receipt's weights_digest named the weights that answered. Nothing recorded when a backend's weights changed, from what, or whether the change was planned. Weights could be swapped under a running steward, and every later receipt simply named the new digest.

The record (mesh-receipt `change`, SPEC §6.5)

A ChangeLog per backend: a hash-chained sequence of JCR-1 entries (mesh_change: "mesh/1"), sealed under the steward key that seals its receipts.

Plan entries record, before the changes they cover:
- the precisions a change may run at;
- the fidelity floor;
- the validation every change must pass;
- what the plan foresees;
- an optional risk-assessment digest.
Weights entries record one change:
- from and to;
- precision and fidelity;
- the plan it falls under, or none;
- the digest of its validation result;
- effective_from, the first receipt-log sequence served on the new weights;
- a reason.
Checked as they join. Entries are checked by append when they are made and by from_sealed when a party reads a record it was handed:
- chaining and time order;
- from must be the weights in effect;
- the change must change something;
- effective_from must not go back;
- a planned change must name an earlier plan entry and stay inside it (recipe, precision, fidelity floor, validation result).
Plan order. A plan covers only what is sealed after it, so "planned" means foreseen before the change, by the chain's own order. An unplanned change is recorded as unplanned, with no judgement made.
covers(receipt) names the change in effect at the receipt's sequence, matched on backend, recipe, weights and precision. A log position orders changes against receipts without trusting a clock; made_at is the steward's statement of the time.

The gate (mesh-core)

record_weights swaps an engine in only by recording the change first.
plan_changes records a plan.
govern holds a restarted steward to its persisted record. The record must verify, hold, match the running engine, and not apply ahead of the receipt log.
change_log exposes the record.
Once a backend has a record:
- a serve on weights the record doesn't have in effect, or on none, is refused before any grant is decided or work runs;
- a serve whose engine reports other weights, or none, is not sealed.

Verification (build host)

mesh-rs: 105 tests (11 new) plus 19 behind features.
- clippy -D warnings and rustdoc -D warnings are clean.
- The conformance pack is unchanged.
Mutation testing: 27 mutants; 26 killed, and the 27th is equivalent (a no-op).
- In the first round, the backend, seq and prev checks survived because each was only tested in combination with the others.
- A single-rule test now kills each one.
Repo checks pass.

Still open from #6

The disclosure bundle beside cra.rs, as a separate PR in jouleclaw-compliance.

🤖 Generated with Claude Code

Sweep 2026-10-19 item #6, second part. A receipt's `weights_digest` named the weights that answered. Nothing recorded when a backend's weights changed, from what, or whether the change was planned. Weights could be swapped under a running steward, and every later receipt simply named the new digest. ## The record (mesh-receipt `change`, SPEC §6.5) A `ChangeLog` per backend: a hash-chained sequence of JCR-1 entries (`mesh_change: "mesh/1"`), sealed under the steward key that seals its receipts. - **Plan entries** record, *before* the changes they cover: - the precisions a change may run at; - the fidelity floor; - the validation every change must pass; - what the plan foresees; - an optional risk-assessment digest. - **Weights entries** record one change: - `from` and `to`; - precision and fidelity; - the plan it falls under, or none; - the digest of its validation result; - `effective_from`, the first receipt-log sequence served on the new weights; - a reason. - **Checked as they join.** Entries are checked by `append` when they are made and by `from_sealed` when a party reads a record it was handed: - chaining and time order; - `from` must be the weights in effect; - the change must change something; - `effective_from` must not go back; - a planned change must name an *earlier* plan entry and stay inside it (recipe, precision, fidelity floor, validation result). - **Plan order.** A plan covers only what is sealed after it, so "planned" means foreseen before the change, by the chain's own order. An unplanned change is recorded as unplanned, with no judgement made. - **`covers(receipt)`** names the change in effect at the receipt's `sequence`, matched on backend, recipe, weights and precision. A log position orders changes against receipts without trusting a clock; `made_at` is the steward's statement of the time. ## The gate (mesh-core) - `record_weights` swaps an engine in only by recording the change first. - `plan_changes` records a plan. - `govern` holds a restarted steward to its persisted record. The record must verify, hold, match the running engine, and not apply ahead of the receipt log. - `change_log` exposes the record. - Once a backend has a record: - a serve on weights the record doesn't have in effect, or on none, is refused before any grant is decided or work runs; - a serve whose engine reports other weights, or none, is not sealed. ## Verification (build host) - **mesh-rs:** 105 tests (11 new) plus 19 behind features. - `clippy -D warnings` and `rustdoc -D warnings` are clean. - The conformance pack is unchanged. - **Mutation testing:** 27 mutants; 26 killed, and the 27th is equivalent (a no-op). - In the first round, the backend, `seq` and `prev` checks survived because each was only tested in combination with the others. - A single-rule test now kills each one. - **Repo checks** pass. ## Still open from #6 The disclosure bundle beside `cra.rs`, as a separate PR in jouleclaw-compliance. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit

2026-10-21 05:19:14 -04:00

mesh/1: a signed weights change record, and a gate that holds a backend to it

standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 6s

Details

standards workspaces build + test / macOS energy backends (pull_request) Has been skipped

Details

repository checks / lockfiles, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 1m3s

Details

standards workspaces build + test / joulehook-rs (joulehook/joulehook-rs, joulehook-rs, linux) (pull_request) Successful in 1m17s

Details

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 2m1s

Details

a4be353a16

A receipt's weights_digest named the weights that answered, and nothing
recorded when a backend's weights changed, from what, or whether the change
was planned. Weights could be swapped under a running steward, and every
later receipt simply named the new digest.

mesh-receipt::change (SPEC §6.5):
- A per-backend ChangeLog: a hash-chained sequence of JCR-1 entries
  (profile tag mesh_change) sealed under the steward key that seals its
  receipts. Each entry carries backend, recipe, seq, prev and made_at.
- A plan entry records, before the changes it covers, the precisions a
  change may run at, the fidelity floor, the validation every change must
  pass, what the plan foresees, and an optional risk-assessment digest.
- A weights entry records from, to, precision, fidelity, the plan it falls
  under or none, the digest of its validation result, effective_from (the
  first receipt-log sequence served on the new weights) and a reason.
- Entries are checked as they join, by append when made and by from_sealed
  when read. The rules: chaining; time order; from must be the weights in
  effect; the change must change something; effective_from must not go
  back. A planned change must name an earlier plan entry and stay inside it
  (recipe, precision, fidelity floor, validation result). A plan therefore
  covers only what is sealed after it. An unplanned change is recorded as
  unplanned.
- covers(receipt) names the change in effect at the receipt's sequence,
  matched on backend, recipe, weights and precision. A position orders a
  change against receipts without trusting a clock.

mesh-core:
- record_weights swaps an engine in only by recording the change first;
  plan_changes records a plan; govern holds a restarted steward to its
  persisted record; change_log exposes the record.
- Once a backend has a record, a serve on weights the record does not have
  in effect (or on none) is refused before any grant or work. A serve whose
  engine reports other weights, or none, is not sealed.

Tests:
- mesh-receipt: 7 new. Read-back; tampering; each chaining rule alone;
  change order; inside-the-plan; plan order; coverage.
- mesh-core: 4 new. Unrecorded swap refused before the meter is read; an
  engine that forgets its weights after serving; a planned change held to
  its plan with the old weights kept on refusal; restart from the persisted
  record, including tampered, foreign-key and ahead-of-log records.
- Mutation testing: 27 mutants. 26 killed; the 27th is equivalent (a no-op
  `.or(None)`). Three survived the first round, the backend, seq and prev
  checks each tested only in combination; the single-rule test was added
  and kills them.

Verified on the build host: mesh-rs 105 tests plus 19 behind features;
clippy -D warnings and rustdoc -D warnings clean; the conformance pack is
unchanged. Repo checks pass.

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

dcharlot referenced this pull request

2026-10-21 05:28:05 -04:00

jouleclaw-compliance: a scoped PLD disclosure bundle, and a crosswalk to the provisions #384

dcharlot merged commit 8f41bb0acc into main

2026-10-21 07:29:47 -04:00

dcharlot referenced this pull request from a commit

2026-10-21 07:29:50 -04:00

Merge pull request 'mesh/1: a signed weights change record, and a gate that holds a backend to it' (#382) from feat/mesh-weights-change-record into main