open-standards/wai/oer-conformance/settle/README.md
Transaction Science 1f5bfbd1e0 wai: no modelled or zero figure shown as a measurement
- The C settlement kernel graded every receipt measured, from hardware, by
  hardware_meter, whatever its meter; it now writes the grade and device the
  meter states. Its host harness's figures are constants: projected, from a
  simulation, by model_estimated (oer-receipts §2: an Estimator figure is
  projected). The Zephyr skeleton states projected and no longer seals a
  compute figure of 0. firmware_vectors.json is regenerated; both verifiers
  pass it.
- wai-web: the world demo seals the page's estimate labelled Estimator and says
  so on screen (label_page_figure, tested); the quantum demos seal the unmetered
  marker instead of invented constants, and their getters say a 0 is unmetered.
- The quantum studio shows a figure with its class, coverage and uncertainty;
  the quantum CLI prints the unmetered marker as unmetered (tested); the
  metering tools head a bracket as a bracket and print the marker on stdout when
  they seal it; a provenance total names the class it reads at (tested).
- energy-measurement §2.8 and §6 record which demos still seal an illustrative
  figure the page passes in.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 2a8d45aa0d)
2026-10-26 08:30:49 -04:00

30 lines
2.2 KiB
Markdown

# settle: the settlement kernel in portable C
The keystone loop as code that runs on a microcontroller and on a host: canonicalize a question, hash its key,
look it up, verify, decide with compiled rules, record with a validity window, and emit an OER/2 receipt
(draft 0.1 as profiled by [`extensions/oer-receipts.md`](../../extensions/oer-receipts.md)): canonical bytes in the envelope's fixed order, SHA-256 receipt id and chain hash, Ed25519 signature.
Files: `settle.c/.h` (the kernel), `sha256.c/.h`, `tweetnacl.c/.h` (public domain Ed25519), `host_main.c`
(host harness with a modelled meter), `zephyr/` (application skeleton for a Zephyr board; untested build).
Build and cross-verify against the Python reference verifier from the OER/2 vector set:
make
./settle_host firmware_vectors.json 400
python3 ../oer2_verify.py firmware_vectors.json # PASS v10 firmware chain from the C kernel
cmp firmware_vectors.json ../firmware_vectors.json # the pinned corpus: no drift
The harness writes 400 receipts, the records they cite and a ledger identity; the verifier checks canonical
bytes, ids, chain, sums, floors, records and signatures. Two implementations, one receipt — three with `wai_oer_vectors` in `wai-rs`, which CI runs over this output.
What the kernel does not do yet: escalate new questions upstream (a callback hook is the next addition),
read a rail meter (the host models one; the Zephyr skeleton counts cycles), and hold the signing seed in a
secure element. Energy constants inside the kernel (cycle energy, bits committed) are the model's projected
values until the bench node measures them.
So no receipt here is a reading. The kernel writes the grade and the device the meter states
(`settle_meter_t.how`, `.device`) and no longer fixes them to `measured` from `hardware`: the host harness
states `projected`, from a `simulation`, by the method `model_estimated`, and the Zephyr skeleton
`projected` on `hardware` by the same method (oer-receipts §2: a figure computed from constants is an
`Estimator` figure, graded `projected`). The ledger's `meter_joules` is the sum of those projected figures,
and the harness says so when it prints it.