mavai v0.20.1

The mavai report renderer, v0.20.1. Download the asset for your platform and verify against SHA256SUMS — see the repository README. Packaging a distribution that carries this renderer: fetch-binary.sh does the download and the verification.

mavai v0.20.0

The mavai report renderer, v0.20.0. Download the asset for your platform and verify against SHA256SUMS — see the repository README. Packaging a distribution that carries this renderer: fetch-binary.sh does the download and the verification.

mavai v0.19.1

The mavai report renderer, v0.19.1. Download the asset for your platform and verify against SHA256SUMS — see the repository README. Packaging a distribution that carries this renderer: fetch-binary.sh does the download and the verification.

mavai v0.19.0

The mavai report renderer, v0.19.0. Download the asset for your platform and verify against SHA256SUMS — see the repository README. Packaging a distribution that carries this renderer: fetch-binary.sh does the download and the verification.

mavai v0.18.0

The mavai report renderer, v0.18.0. Download the asset for your platform and verify against SHA256SUMS — see the repository README. Packaging a distribution that carries this renderer: fetch-binary.sh does the download and the verification.

mavai v0.17.0

The mavai report renderer, v0.17.0. Download the asset for your platform and verify against SHA256SUMS — see the repository README. Packaging a distribution that carries this renderer: fetch-binary.sh does the download and the verification.

mavai v0.16.0

The mavai report renderer, v0.16.0. Download the asset for your platform and verify against SHA256SUMS — see the repository README.

mavai v0.15.0

The mavai report renderer, v0.15.0. Download the asset for your platform and verify against SHA256SUMS — see the repository README.

mavai v0.14.0

The mavai report renderer, v0.14.0. Download the asset for your platform and verify against SHA256SUMS — see the repository README.

mavai v0.13.0

The mavai report renderer, v0.13.0. Download the asset for your platform and verify against SHA256SUMS — see the repository README.

Twelve changes from reading the first real reports, plus the structural change that stops them diverging again.

One postcondition block for all four report types

The measurement, optimization and verdict reports still drew the old bar-and-triple standings tables while the exploration report had moved to grids, badges, fraction cells and outcome-class panels. One artefact looked like a different product from the next, and every stylistic change had to be made four times or not at all.

They now reach one renderer through the standings view all four already built, so alignment is a property of the code rather than a discipline. The per-report standings matrices, by-path pivots, grouped tables and attainment bars retire with them — the new block keys a check on its stated path and form, so the separate by-path pivot was already the row identity.

The optimize report gains the configuration key and the latency block, matching exploration. Where a configuration is described by its overrides of a base, an iteration is described by what the stepper changed to reach it — which is what connects a score to a decision. Iteration columns run in execution order, never the leaderboard's: an iteration is its position in the search.

Identity stops encoding rank

A badge sat beside the rank column and re-encoded it, buying nothing and paying for it with instability in every block below, where the badge is the only identifier — so seeing "(1)" meant scrolling back to the leaderboard.

A Configurations key now names each one once, before first use: badge, name, and how it differs from the base. The base takes 1, the rest follow stated order, and every block follows the badge. The overrides-from-base chips move into that key, because they are the configuration's description and belong where identity is stated rather than in a table of results.

Cells state their denominator

A bare failing count could not say how many samples stood behind it, and denominators differ per configuration. Cells now read passed/samples on a quality gradient: only a clean sweep is green, none-passed is red, anything between is amber. A check nothing was judged on reads —/6 in the delivery hue rather than 0/6 in red, which would send a reader hunting for a failed assertion that does not exist. The denominator is every sample, never the judged ones.

Also

• A postcondition that held renders one line, not one per distinct passing reply — four green ticks left a reader unsure whether the check had failed.
• The observed-value disclosure appears only where it reveals materially more, and is named for what it is: what the emitter recorded, not what the service returned.
• The latency block wears the same frame as every other block, draws its axis, prints its values, and stops flagging a lone sample as the "slowest" of one in red.
• A configuration that delivered but never passed plots its stated average as a hollow ring — the block could not previously answer its most ordinary question: which of these is fast? One that delivered nothing stays as prose, since its average is the peer's timeout ceiling.

Reports remain single self-contained files with no JavaScript: every disclosure is a native <details> and the grids are CSS.