Runtime & Integrations · Runtime Harness

HTML report

A self-contained dashboard rendering of the Scorecard. next

report.html is a human-facing rendering of scorecard.json — the same typed Scorecard the Markdown and terminal sinks render, drawn as a scannable dashboard. The CLI writes it alongside report.md; the page adds no authority and holds no verdict of its own. Built in the framework; not yet in the version the plugin installs.

A report is the most tempting place for authority to leak in as prose. The HTML sink prevents it the same way the others do: render(scorecard) takes immutable typed data and returns one self-contained string — pure, no I/O, no network — so it can never claim more than the Scorecard holds, and it cannot change a verdict or an exit. The headline verdict word is read from scorecard.verdict.verdict, never written as a literal token.

What the report renders

Every region is derived from a typed field of the Scorecard — nothing is computed here:

RegionReads fromWhat it shows
Verdict heroscorecard.verdictThe verdict word and its description, with a hue per verdict; ci_should_fail is shown as “exit zero / non-zero.” It renders the verdict; it does not decide it.
KPI tilesscorecard.metricsCounts only — metrics, scored, non-evaluable, judge (uncal.), active gates, examples. A non-evaluable metric is counted, never folded into a value.
Per-metric interval bandthe metric point + its Estimate/IntervalA [0,1] track with the Wilson / Student-t [lower, upper] band shaded and the point marked — the honest uncertainty made visual. No interval → the band is drawn as an honest absence, not a fabricated width.
Tier & authority chipsscorecard.authorityA runtime / judge / reference tier per metric plus its typed authority reasons as chips — never a granted authority the records don’t hold.
“What this run does not claim” paneltyped authority + baseline_stateDerived caveats: the run is informational, judge metrics are uncalibrated, non-evaluable metrics are an honest absence, and the baseline comparability state.
Delta vs previous runoptional prior per-metric pointsPer-metric movement chips (▲/▼) and a summary; a convenience only, labelled raw point movement — “a move inside the interval is noise.” A missing or garbled prior run is simply “no delta,” never affecting the verdict or exit.

Where a metric has failure clusters, the report renders scorecard.clusters as explanatory sub-rows (a failure code and its case count) — the same typed grouping report.md uses, shown by count and never as a 0.0.

A rendering, never a second verdict

Like the Markdown and terminal sinks, the HTML sink derives each gate’s display state through the shared gate_state helper and takes the verdict straight from scorecard.verdict. It produces derived output: scorecard.json and runrecord.json remain the source of truth, and CI reads the exit code or the JSON — never the rendered page. The report is one more view of the one typed source, not a second path to a verdict.

Self-contained, offline, and honest by construction The page inlines its own CSS and draws the interval bands as inline SVG — no external assets and no network, so it is CSP-safe and works offline. It is theme-aware (dark by default, with a light mode). Its footer states plainly that the verdict comes from the Verdict Engine and this page adds no authority.

An illustrative report

A fresh run with no active gate renders an informational verdict — the hero says so, and the honesty panel names what the run does not claim:

  • This run is informational — a non-failing result is not proof of quality.
  • Judge metrics are uncalibrated — they cannot gate until a host computes an agreement study against SME labels.
  • Metrics that scored nothing are non-evaluable here — an honest absence, never a fabricated 0.

Illustrative example, not a measured result. An informational report is never a green “pass”; the panel is the point.

Next steps