AxonOS Validation Record

This is the validation record: the maintained collection of reference-hardware measurement traces and their post-processing, which together form the L2 artefacts that VALIDATION.md Section 3 requires and that CLAIMS.md links. Each trace here is the evidence beneath one L2 figure in the claims catalogue, and the reference post-processor (postprocess.py) is the deterministic step from the raw trace to the headline figure, so that a reviewer can re-derive any catalogued L2 value from the data with nothing but Python.

What is — and is not — in this record

A trace appears here only after it has been measured on the reference hardware. This record contains no fabricated, simulated, or placeholder measurement: a number that has not been measured is not in a trace, and a claim whose trace is not yet here remains, in CLAIMS.md, explicitly publication pending. The traces/ directory is empty until real runs populate it, and its emptiness is honest rather than hidden — it is the visible counterpart of the catalogue's "publication pending" status, in the spirit of VALIDATION.md Section 5.3.

The discipline is asymmetric on purpose. The post-processing, the trace format, and the procedure — everything except the measurements themselves — can and should be prepared in advance, so that publishing a trace is a drop-in operation the moment the measurement exists. That preparation is what this record currently holds. The measurements are what it awaits.

The claims this record substantiates

Each row maps a CLAIMS.md entry to the trace that will substantiate it and to the exact postprocess.py invocation whose output must reproduce the catalogued figure. Until the trace file exists, the catalogue entry stays publication pending; when it exists, its catalogue artefact link points into this record.

CLAIMS entry	Headline figure	Trace file (when measured)	Reproduction command
C-1·L2	worst-observed end-to-end response time; deadline misses	traces/wcrt-soak.csv	postprocess.py traces/wcrt-soak.csv --column response_time_us --deadline-us 1000
C-2	observation-cadence jitter, σ	traces/jitter-soak.csv	postprocess.py traces/jitter-soak.csv --column interval_us
C-3·L2	IPC slot latency, measured	traces/ipc-latency.csv	postprocess.py traces/ipc-latency.csv --column slot_us
C-4·L2	consent-withdrawal time, median / worst	traces/consent-withdraw-soak.csv	postprocess.py traces/consent-withdraw-soak.csv --column withdraw_cycles
C-5 (input)	baseline-OS jitter, σ (the divisor of the derived factor)	traces/jitter-baseline.csv	postprocess.py traces/jitter-baseline.csv --column interval_us

The improvement factor C-5 is then derived by dividing the C-2 σ by the baseline σ; the division is recorded in CLAIMS.md, with both inputs cited, and both inputs are traces in this record.

The procedure for publishing a measurement

1. Measure on the reference hardware, under the conditions TRACE-FORMAT.md requires, emitting a raw CSV trace plus its metadata header.
2. Commit the raw trace to traces/, unmodified. The raw trace is the artefact; it is never edited to fit a claim.
3. Derive the headline figure by running the mapped postprocess.py command, and record its output in the trace's metadata.
4. Catalogue: in CLAIMS.md, replace the entry's "publication pending" with the value the post-processor produced and a link to the trace here. The value in the catalogue must be exactly what step 3 produced.
5. Re-checkable thereafter: anyone may re-run step 3 against the committed trace; the result must match the catalogued figure, or the claim is falsified and re-graded under VALIDATION.md Section 6.

Re-checking a published claim

Re-checking needs only this record and Python:

python3 postprocess.py traces/<trace>.csv --column <column> [--deadline-us <d>]

The printed headline figure must equal the value CLAIMS.md records for the corresponding entry. A discrepancy is not a rounding curiosity to be smoothed over; it is a falsification, to be handled by the re-grading discipline.

Toward L3

Everything here is L1-and-L2 machinery: proofs (linked from CLAIMS.md) and measurements (here). L3 — independent reproduction — is not a file the Project can add to this record by itself, because its defining property is independence. When the first independent reproduction occurs (the worst-case response time, C-1·L2, is the intended first target, per ROADMAP.md Phase 1), its signed report becomes the L3 artefact, recorded in CLAIMS.md and, if the reproducing party permits, mirrored here.

---

— The AxonOS Project · Singapore · Zurich · Berlin · Milano · San Mateo