| Filename | Latest commit message | Latest commit date |
|---|---|---|
fca3f76e51
The monorepo's IOReport energy backends now decline unless the CPU energy rail keeps advancing: on macOS 27 an unprivileged reader sees the CPU rails frozen or republished only in rare lumps, so a meter that trusted a present counter reported CPU work as GPU-only energy, or as zero, while tagging it a reading. The owner's decision is that a vendor energy counter is a real reading (the trust gap is provenance, not accuracy), so a LIVE reading is graded as a hardware reading, and every spec that grades vendor counters now carries the same rule: A reading from a vendor energy counter (RAPL, NVML, Apple IOReport, ...) MAY be graded as a hardware reading only while the counter is demonstrably live for the domain the figure claims: the implementation MUST have observed the counter covering that domain advance under load (for Apple IOReport: the CPU energy rail itself advancing in at least 5 sample intervals, in at least 4 of every 5, over at least 300 ms while the probing thread burns CPU). A counter that is present but not live - frozen, or republished in lumps - MUST NOT produce a hardware-graded figure; the implementation falls back to its estimator or reports the work unmetered, and SHOULD record why. A figure MUST NOT claim coverage of a domain its counter does not read; where the format has a coverage field, such a figure is Partial. Joule Code - spec/receipt.md §2 (REQUIRED): HwShunt now reads "an external shunt, or a vendor energy counter (RAPL, NVML, Apple SMC/IOReport) while that counter is live"; the rule above is added verbatim, and in this receipt the hardware grade is a present measured_uj and the HwShunt tag, so a counter that is not live supplies neither. The §1 comment and §5 say "live". - SPEC.md §6: the provenance definition now names IOReport and NVML beside RAPL/SMC, measured_uj comes only from an interface live for the domain it claims, and a paragraph states the MAY/MUST NOT, pointing to receipt.md §2 for the test. The §9 readiness row says "live" and "not live". - ROADMAP.md v0.2 "Measured energy": a vendor counter feeds the HwShunt path only while live; where it is present but not live (IOReport's CPU rails to an unprivileged reader on macOS 27) the receipt stays on the estimator. - examples/l3-jouleclaw/README.md: the claim that the receipt is "a real local measurement ... (HwShunt on RAPL/NVML hosts; Estimator on Apple Silicon until IOReport is wired)" was wrong both ways: run.rs wires only Apple Silicon's counter, and other hosts fall to the token Estimator. It now says so, that the counter's own tag is carried, and that HwShunt needs a live counter. - joule-code-receipt: the Provenance::HwShunt doc comment says the same. - CHANGELOG.md [Unreleased] ### Changed: the rule; no wire or vector change. Sense - SPEC.md §7 (REQUIRED): measured_uj comes only from a live interface; the rule is added verbatim. The Sandbox PowerMeter was described as "(real RAPL/IOReport)"; it is now described as grading a reading HwShunt only while its counter is live and falling back to its estimator otherwise, which is what origin/sandbox-meter/cpu-rail-liveness implements. §10's Sandbox edge says the same in brief. - sense-schema: the HwShunt, Energy and Energy::measured doc comments say a vendor counter is a hardware reading only while live. - Sense keeps no CHANGELOG, so none is added. Other specs that grade vendor counters - map/spec/receipt.md §2: the HwShunt row read "RAPL/SMC/shunt"; it now names a counter "while it is live", and the rule is added verbatim, noting that Receipt::seal cannot check liveness (the meter's duty, upstream). map/SPEC.md §6 states the MUST NOT and points there. CHANGELOG.md gains an [Unreleased] ### Changed entry; no wire or vector change. - arl/ARL-S.md, Telemetry: physical telemetry is what gates tiers above 0, and it said energy is "measured directly via RAPL ... NVML". The rule is added in ARL-S's own terms and lower-case keywords (ARL uses no RFC 2119 capitals): a counter that is not live does not produce physical telemetry, the energy it would have covered is reported unmetered, and the Supervisor must have observed the counter advance. No version bump. - smart-byte treatise §8.6: "Where RAPL or equivalent hardware energy counters are available, the measurement is read from the hardware" now requires the counter to be demonstrably live, and a frozen or lump- republished counter yields the same honest zero as an absent one. Text and doc comments only: no code path, wire format, or conformance vector changes. joule-code-rs (joule-code-receipt, joule-code-conformance) and sense-rs (sense-schema, sense-conformance) build and test clean, their rustdoc builds under -D warnings, map-rs (map-receipt, map-conformance) tests pass, `joule-code-conformance verify ../conformance/v1` passes 24/0/0, the no-vanity-metrics check passes, and every relative link in the changed Markdown resolves. Co-Authored-By: Claude Opus 5.5 <[email protected]> |
||
| .. | ||
| arl-rs | ||
| vocab | ||
| ARL-S.md | ||
| ARL.md | ||
| LEXICON.md | ||
| LICENSE | ||
| RATIONALE.md | ||
| README.md | ||
ARL — AI Readiness Level
A universal, vendor-neutral standard for measuring the readiness of an AI system to perform a defined task in a defined context.
ARL is to AI what the Technology Readiness Level scale (NASA, 1974) is to technology: a portable yardstick that says how ready a thing is, independent of who built it, what it is made of, or which lab is making the claim. It is tied to no model, no runtime, no vendor. Any AI system — a frontier API, a local model, an agent harness — gets an ARL score, and the score means the same thing everywhere because each axis is anchored in math or physics that does not change across time, languages, or political regimes.
Every ARL score has four required parts. None summarizes the others.
- Validation Depth (1–9) — how thoroughly the readiness claim has been tested. Statistics.
- Convergence Class (A–E) — how stochastic the system is on the certified task. Stochastic process theory.
- Energy Profile (joules) — training-amortized, per-task inference, total cost of operation. Thermodynamics.
- Security Class (S0–S4) — adversarial robustness, output integrity, confidentiality, auditability. Information theory and cryptography.
A score is assigned to a specific system + task + context on specific hardware. Change any of them and you score again. The four axes cover what the system is, what it does, what it costs, and how it holds up under attack.
The teeth of the framework are the cross-axis gates: a high validation depth is unreachable without a matching convergence class and security class (ARL ≥ 4 ⇒ Class D + S1; ≥ 6 ⇒ C + S2; ≥ 8 ⇒ B + S3; 9 ⇒ S4), refusing to disclose energy caps the score at ARL 3, refusing security methodology caps it at S0, and the published methodology must predate the published claim. A claim that omits any of the four parts is incomplete by definition.
Contents
ARL.md— the four-axis readiness scoring framework.ARL-S.md— the ARL Sandbox: the testing environment, isolation tiers, telemetry, attestation, and replay requirements inside which scores are measured. Composes named open-source components (seccomp/gVisor/Firecracker for isolation; RAPL/NVML/Zeus for energy; Ed25519-over-JCS + SHA-256 for attestation) — no component is mandated by brand, only by capability.LEXICON.md— the controlled vocabulary for ARL claims, so a stated score has one meaning.RATIONALE.md— Why ARL: the trends in AI that make a shared readiness yardstick necessary, the reasoning behind the four axes, and how ARL composes with the governance frameworks and benchmarks already in use worldwide. Background, not part of the normative spec.
The first three documents are self-contained: a reader can understand and use the framework with only those. RATIONALE.md is the why behind them.
Status
Document stack v1.3 (May 2026). The standalone, system-agnostic reference implementation has begun: arl-rs/ ships arl-core — the four-axis claim model with every cross-axis gate enforced (a high validation depth is unreachable without matching convergence and security; energy non-disclosure caps the score at ARL 3; security non-disclosure caps the class at S0; methodology must predate the claim) and the LEXICON controlled vocabulary enforced (terms with no single operational definition, such as AGI or consciousness, cannot anchor a claim because they cannot be measured; terms with a measurable operational sense are flagged to confirm that sense is intended — the lexicon takes no position on the terms themselves). Zero coupling to any runtime. arl-sandbox ships the ARL-S Supervisor core: the evaluation-session model, the tier↔ARL↔telemetry structural gates (isolation must match the ARL range, all three telemetry categories required above Tier 0, Tier 2/3 must be replayable, detected tampering invalidates), and the attestation — Ed25519 (RFC 8032) over JCS-canonicalized JSON (RFC 8785) with SHA-256 — so a measurement is tamper-evident and content-addressable, verifiable by anyone with no trust in the issuer. It also ships a trait-based Supervisor orchestration layer: drive a Harness (the task runner — reference EchoHarness needs no model), sample a PhysicalTelemetrySource (energy; NullPhysicalSource / FixedPhysicalSource, with RAPL+NVML as the Linux deployment slot), assemble the session with the telemetry categories actually captured, and sign it — evaluate() returns a signed, validated Evaluation. An environment with no energy meter honestly reports physical telemetry absent, which caps the achievable tier. (Launching the real isolation tiers — seccomp/gVisor/Firecracker — and reading RAPL/NVML/TPM is OS- and hardware-specific deployment glue behind the traits, composed from the neutral components ARL-S names; not in this crate.) And arl-cli — the arl reference checker: arl validate <claim.json> runs the cross-axis gates and exits 0/1 so a claim that fails the ARL gates fails your build; arl lint reports controlled-vocabulary findings; arl verify <session.json> <attestation.json> checks an attestation; arl explain prints the axes and gates. A Claim is plain JSON — missing fields default to the uncharacterized floor, and an out-of-range validation depth is rejected at the parse boundary.
And arl-wasm — the same arl-core gates compiled to WebAssembly (single-sourced; no JS reimplementation to drift), so a browser playground validates a claim live. The playground + spec site lives in the separate arl-web/ project (not this repo), an Astro site that renders the spec and bundles the WASM checker. The compiled WASM was verified executing in a real runtime — a downgraded claim reports its gate violations, a term with no operational definition cannot anchor the claim — identical to the CLI.
arl-rs/ is covered by a test suite, depends on nothing but arl-core + neutral crypto/wasm crates. The multi-node sandbox, edge tier, non-NVIDIA accelerator telemetry, and continuous-evaluation framework remain deferred.
Lineage
ARL adapts the Technology Readiness Level scale (NASA 1974; nine levels per Mankins 1995; ISO 16290:2013) and applies measurement disciplines from ENERGY STAR (energy), pharmaceutical efficacy / radar Pd-Pfa / bit-error-rate practice (convergence), and the CIA + non-repudiation discipline of NIST SP 800-53, ISO/IEC 27001, and Common Criteria EALs (security). Hardware documentation discipline draws from DoD SWaP-C2 reporting.
Licence
CC-BY-4.0 (see LICENSE) for the specification text. The forthcoming reference implementation will carry Apache-2.0.
ARL is owned by no one. Transaction Science is one steward — it publishes the specification and writes the reference implementation; the standard itself is public and forkable.