open-standards/eoc/eoc-rs/crates/eoc-carbon/src
Repository files (latest commit first)
Filename Latest commit message Latest commit date
David Charlot 44eae552a2 eoc: bind a published facility band to the allocation it came from
A band published on its own is unfalsifiable: a letter, a facility name, and
nothing a reader can check. `FacilityRating` carries the commitment to the share
set the rating aggregates, so the tenant proof from `Allocation::proof_for`
verifies against **the same root the public rating cites**.

That join is the point. A tenant can confirm its own consumption sits inside the
very set that produced the published label, without seeing any co-tenant — which
is the only thing that makes a facility label mean anything to the customers it
was derived from. `admits()` checks the proof against the receipt's root *and*
that the totals agree, so a proof that is internally valid against a different
period is rejected rather than quietly accepted.

**Assurance is derived, not stored.** The obvious design is a `verified: bool`
or an assurance level written into the artifact, and that would repeat the
failure the band itself had: a claim about evidence, asserted by the party under
audit. So there is no assurance field. `assurance()` takes a `SignatureStatus`
the caller must supply, and an attestation that nobody checked yields
`AttestedUnverified` — never `Verified`. An unchecked signature is a string; it
becomes evidence when someone checks it, and the type makes skipping that step
impossible to do silently. A failed check reports `AttestationInvalid`, which is
strictly worse than no attestation: someone tried to pass off a bad signature.

This crate does no signature verification at all, and says so. There is no
signing dependency in this workspace, and manufacturing a `Verified` state it
cannot substantiate is exactly what the rest of the module refuses to do.

`RatingRecord` is data, not a dependency on whichever crate produced the band: a
receipt records *what* was rated, not *how*. It carries the scale id, metric,
unit and measured value, so a reader re-derives the letter against the cited
scale instead of trusting it — and a band whose scale is unstated is not
comparable to any other band.

The signed preimage covers every field that makes the rating a claim (band,
value, scale, basis, residual, commitment), with length-prefixed fields so
shifting a character across a boundary cannot produce the same bytes. Attaching
an attestation does not change what it signs.

Verified: 36 eoc-carbon tests pass (7 new), no clippy warnings in either new
file. One test assertion was corrected rather than the code: with an odd leaf
count a promoted node has no sibling at that level, so the aggregate count
varies between tenants — the guarantee is the bound, not a fixed number.
2026-08-27 13:32:23 -04:00
..
account.rs ingest batch 5 (salvage): 2 crates from 9-agent dispatch (session-limit hit mid-batch) 2026-05-24 09:28:38 -04:00
allocation.rs eoc: divide a measured facility total among tenants without losing any of it 2026-08-27 13:32:23 -04:00
co2signal.rs ingest batch 5 (salvage): 2 crates from 9-agent dispatch (session-limit hit mid-batch) 2026-05-24 09:28:38 -04:00
electricity_maps.rs ingest batch 5 (salvage): 2 crates from 9-agent dispatch (session-limit hit mid-batch) 2026-05-24 09:28:38 -04:00
error.rs ingest batch 5 (salvage): 2 crates from 9-agent dispatch (session-limit hit mid-batch) 2026-05-24 09:28:38 -04:00
iea_baseline.rs ingest batch 5 (salvage): 2 crates from 9-agent dispatch (session-limit hit mid-batch) 2026-05-24 09:28:38 -04:00
intensity.rs ingest batch 5 (salvage): 2 crates from 9-agent dispatch (session-limit hit mid-batch) 2026-05-24 09:28:38 -04:00
lib.rs eoc: bind a published facility band to the allocation it came from 2026-08-27 13:32:23 -04:00
pue.rs ingest batch 5 (salvage): 2 crates from 9-agent dispatch (session-limit hit mid-batch) 2026-05-24 09:28:38 -04:00
rating.rs eoc: bind a published facility band to the allocation it came from 2026-08-27 13:32:23 -04:00
scheduler.rs ingest batch 5 (salvage): 2 crates from 9-agent dispatch (session-limit hit mid-batch) 2026-05-24 09:28:38 -04:00
sci_bridge.rs ingest batch 5 (salvage): 2 crates from 9-agent dispatch (session-limit hit mid-batch) 2026-05-24 09:28:38 -04:00
watttime.rs ingest batch 5 (salvage): 2 crates from 9-agent dispatch (session-limit hit mid-batch) 2026-05-24 09:28:38 -04:00