ac387a1db5
Departures from OER/2 draft 0.1, each in extensions/oer-receipts.md §9: - decisions are named oer.decision.*, not wai.settle.* (WAI's namespace is for payload formats) - the stage list behind bundle.provenance_root is serialised exactly as the body is, pinned by a non-ASCII fixture - the number profile is normative: I-JSON integers, decimal strings in JSON's number grammar (<=34 digits), anything else malformed - a document outside the document profile is refused whole: a number whose nearest binary64 is infinite, NaN/Infinity, an unpaired surrogate, a repeated member name, nesting past 64 - every composition check is exact (num-bigint / exact decimal context), ln 2 pinned as a decimal, every tolerance scaled by the figure's magnitude - the order of the reasons reported alone, and every member judged on its value, are stated, so each mistyped member has one named reason - published Ed25519 keys are decoded strictly: canonical encoding, not small order - abstention is its own outcome (abstain, no answer, no record), held by a new reason, abstention_settled; escalate is a verdict returned from upstream Four rounds of adversarial review with differential fuzzing drove this; the last fuzz found one remaining divergence (repeated member names), now refused by both. The edge corpus grows to 99 hand-declared vectors plus unreadable/ (11 documents every verifier must refuse); each rule was falsified in both verifiers. serde_json gains float_roundtrip under the oer feature so Rust rounds as Python does. Co-Authored-By: Claude Opus 5.5 <[email protected]>
1.6 KiB
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): 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.