Protocol-first energy measurement

Wattch

A Rust daemon and CLI boundary for local energy and system-telemetry capture, designed around explicit evidence classes, deterministic validation and replayable traces.

Back to selected work

Role: Chakib designed the daemon/client boundary, protocol and validation model, built the RAPL prototype and evolved it into a backend-independent trace-first foundation with deterministic test scenarios.
Current status: The public v0 Rust prototype proves RAPL, protobuf framing and Unix-socket collection. A local protocol-first rewrite adds replayable trace artifacts and deterministic validation; that rewrite was not publicly reachable during the audit.

Terminal transcript from Wattch's deterministic test daemon — Real dry-run output from the checked-in deterministic laptop scenario; it is protocol evidence, not a hardware-energy claim.

Context and problem

Hardware energy counters can require elevated access, while developers and benchmark tools need a safe, reproducible, unprivileged workflow that does not overstate noisy measurements.

Ownership and contribution

Chakib designed the daemon/client boundary, protocol and validation model, built the RAPL prototype and evolved it into a backend-independent trace-first foundation with deterministic test scenarios.

Responsibilities

Implemented the Rust daemon, CLI and shared protocol/domain crates.
Defined protobuf framing in the v0 prototype and a strict versioned frame envelope in Wattch Core.
Added deterministic scenarios and golden validation before hardware-specific claims.
Documented privilege, peer-authentication, counter semantics and failure behavior.

Architecture and data flow

A privileged acquisition daemon reads raw counters and serves a strict local socket protocol. Unprivileged CLI and Python clients capture source descriptors and sample batches into replayable run artifacts; interpretation stays offline.

Linux RAPL powercap or deterministic source
Rust acquisition daemon
Framed local Unix socket protocol
CLI / Python client
Immutable raw trace artifact
Offline inspect and validation

Engineering decisions

Separate privileged acquisition from unprivileged clients.

RAPL access can require elevation; the Unix socket becomes a narrow, auditable boundary.Alternative not selected: Letting every Python or CLI process read protected counters directly.

Keep the daemon deliberately interpretation-free.

Raw evidence remains replayable while baselines, aggregation and benchmark claims can evolve offline.Alternative not selected: Embedding joules-per-token, scoring or report generation in the hot acquisition path.

Reliability, security and evaluation

Descriptor and sample invariants reject unknown sources and non-monotonic sequences.
A deterministic daemon validates protocol behavior without pretending synthetic values are hardware evidence.
The production-oriented daemon documents socket permissions, Linux peer credentials, stale-socket recovery and partial-source failures.

Outcome and status

The public v0 Rust prototype proves RAPL, protobuf framing and Unix-socket collection. A local protocol-first rewrite adds replayable trace artifacts and deterministic validation; that rewrite was not publicly reachable during the audit.

Technology groups

Systems

Rust, Linux, RAPL, Unix sockets

Protocol

Protobuf, Binary frames, Typed descriptors

Validation

Deterministic daemon, Golden tests, Replayable traces

Proof and source material

Wattch v0 source