| Filename | Latest commit message | Latest commit date |
|---|---|---|
bc658ab98b
`build_consistency_path` returned `vec![old_root, new_root]` — the two values
the operator was already asserting — and `verify` checked that
`audit_path[0] == old_root` and `audit_path.last() == new_root`. That compares a
claim to itself. A log operator serving a split view, two histories sharing no
prefix, produced a "proof" that verified, which is precisely the attack a
consistency proof exists to catch. The verifier's own comment also claimed it
checked that "adjacent pairs hash correctly"; it never did. The in-code note
said a full RFC 6962 §2.1.2 path "is provable as well" — it is, so it is now
what ships.
`subproof` implements §2.1.2 `SUBPROOF(m, D[n], b)` and `verify` implements the
§2.1.3 walk, rebuilding *both* roots from the subtree hashes and comparing. The
old root is recomputed, not re-read, which is the whole difference. Neither root
travels in the path any more, so the forged shape is structurally refused.
The existing `MerkleTree` already used correct RFC 6962 conventions — `0x00`
leaf and `0x01` node prefixes, `largest_power_of_two_lt` splits — and the
inclusion proof was already real, so the proof composes with them unchanged;
all 17 pre-existing tests pass untouched.
Three new tests, each one the old code could not have passed:
- **The forged proof is refused.** A hand-built `[old_root, new_root]` path,
containing no evidence at all, used to verify; it now errors, while the
honest proof for the same transition still verifies.
- **A fork is refused as an extension.** An operator publishes a 3-leaf tree,
then shows an auditor a 5-leaf tree built over a *different* third leaf.
Every hash in that proof is real — only the relationship is a lie. It is
rejected against the published root and accepted against its own, so the
refusal is about the relationship and not a broken prover.
- **Every shape.** All 153 `(m, n)` pairs with 1 ≤ m ≤ n ≤ 17 round-trip:
perfect trees, unbalanced ones, and `m == n`. Each proof is additionally
checked *not* to verify against the neighbouring old root, so a proof binds
one transition rather than a range.
The `audit_path` doc comment said verification "recomputes from the proof's
referenced subtrees", which was aspirational; it is now true, and says which
hashes are in there and that neither root is.
Note this crate still has **zero consumers** — three grep hits, all its own
files — so no JCP decision can yet be given an inclusion proof. That is the
next piece, and it was worth fixing the proof before wiring anything to it.
Third of the "sealed by name / verified not at all" family from the 2026-10-04
sweep: 845e6cc8 (AP2 mandate authority), aa74283e (policy digest), this.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
| .. | ||
| conformance/v1 | ||
| jouleclaw-rs | ||
| scales | ||
| vocab | ||
| LICENSE | ||
| README.md | ||
| ROADMAP.md | ||
| SPEC.md | ||
JouleClaw — Energy-Optimized AI Runtime
The substrate for AI that costs Joules, not tokens.
Capability per Joule, not capability per parameter.
What JouleClaw is
JouleClaw is a pure-Rust, omni-modal AI runtime + harness + agentic layer governed by Transaction Science as an open standard (5th in the open-standards quartet, alongside OpenPay, Smart Byte, EOC, and WAI).
Every operation JouleClaw performs walks an explicit energy-tiered cascade, top to bottom, stopping at the first stage that closes the query:
| Tier | Name | Cost class | What runs here |
|---|---|---|---|
| L0 | Cache | picojoules | Content-addressed cache hits |
| L1 | Lawful | nanojoules | Deterministic, pre-compiled primitive (text/code only) |
| L2 | Embed | sub-millijoules | Matryoshka embeddings + nearest-neighbor + hybrid search |
| L3 | Model | joules | Local SSM / ternary / multimodal / diffusion / etc. |
| L4 | Wire | tens of joules | Remote frontier RPC (escape hatch only) |
L1 (Lawful) is only meaningful for text and code modalities. For image, audio, video and 3D generation, the cascade collapses to L0 / L2 / L3 / L4 — the energy savings come from caching plus dispatch to the cheapest model that meets the quality bar.
Why JouleClaw exists
The mainstream "agentic AI" ecosystem treats inference as the entry point. Every state shift, every tool call, every routing decision runs through a 70-billion-parameter stochastic engine, burning kilojoules to do work that deterministic compute or a hot cache could resolve for microjoules.
JouleClaw inverts the default. Inference is the last resort, not the first. Frozen model weights are less trustworthy than current world state; fresh, provenance-stamped retrieval beats synthesis from training cuts. Every operation is metered in microjoules where the hardware permits it, and in millijoules where it doesn't — the spec is honest about the floor on every platform.
The thermodynamic circuit breaker is the safety mechanism. Set an energy budget; when measured consumption exceeds the budget, the breaker trips and the operation halts. Hallucination loops cannot survive an honest joule ledger.
What's here
| Path | Contents |
|---|---|
SPEC.md |
JouleClaw v1 spec — cascade tiers, energy contract, receipt |
CHARTER.md |
Stewardship pattern (shared across open-standards) |
jouleclaw-rs/ |
Apache-2.0 Rust reference implementation |
spec/ |
Tier specifications, energy provenance, receipt format |
conformance/v1/ |
Signed wire vectors for cross-implementation verification |
Reference implementation
jouleclaw-rs/ is the Apache-2.0 reference implementation in Rust. It
runs on Apple Silicon (M3/M4/M5 with UMA + Metal 4 Tensor APIs), AMD Strix
Halo / Ryzen AI Max, Intel Lunar Lake, NVIDIA Jetson, and discrete
NVIDIA / AMD GPUs.
It is omni-modal: text, code, vision, audio, video, image diffusion, 3D Gaussian splatting, and cross-modal fusion all dispatch through the same energy-tiered cascade.
The MCP tool surface is a JCP consumer: jouleclaw-jcp wraps any
jouleclaw-mcp metered tool so every dispatch is decided by the JCP runtime
against a signed, metered Grant before a byte reaches the tool — the tool's
identity is the content-addressed resource, the call's energy estimate is
debited from the grant's joule budget, and every decision (allow and deny
alike) seals as a JCR-1 receipt. An injected instruction can name an ungranted
tool; it cannot make the gate dispatch it.
Status
v0.1.0 reference implementation in active development. The spec is draft status. Cross-implementation conformance vectors will land with v1.0.0.
License
- Code: Apache-2.0 (see
LICENSE) - Spec text: CC-BY-4.0 (see
spec/LICENSE)