[rwkeyes]

Problem and result

The repository could not answer "what is this fork actually worth against the release it was ported to". The 0.2.13
comparison existed only as a branch report, and re-deriving its numbers from the shipped JSON found three labelling
errors and one unsupported claim. This publishes the comparison as a front-page block with the chart, and makes the
report match its own evidence.

Before: no fork-vs-stock statement on the default branch; the 0.2.13 report said "errored 22 / 21" (those are
successes; the arms errored 0), reported a mean of per-iteration samples as tok/s, and cited "tag commit
fb57f747" (the annotated tag object, not the commit d2f0964). After: the corrected report, the chart, and a
front-page table saying exactly which differences exceed measurement drift and which do not.

Related discussion

none — documentation and evidence only. No source, flag, default or interface changed.

Approach

Validation first, then publication.

1. Re-derived every number from the artifacts. battery/*.json reproduces all eight legs and both metrics;
   guidellm/*.json gives the TTFT medians the report claims (739 / 2,622 / 6,688 / 9,641 ms against stock
   949 / 3,163 / 7,500 / 9,659 ms). Three defects fell out (below).
2. Re-verified the fairness conditions on disk, not from the prose: the two server configs are identical apart
   from paths (conv_route: "on" in both, which stock ignores; thinking_policy: "on" in both) and the two
   data/expert-profile-mine.bin files have the same SHA-256. The measured fork tree is v0.2.13 + 2 commits; the
   three commits after it on port/0.2.13 touch bench/ only.
3. Published the honest claim. The engine is at parity (largest gap 1.1 % on any of eight legs); the server is
   10.8–22.1 % sooner to first token at 1–4 streams, equal at 8. The README states the mechanism (single-shot
   traffic served with the prompt cache off), the drift (2–4 % in this rig), that errors were 0 in both arms, and that
   conversational traffic gets no such win — so a reader cannot mistake this for an engine speed-up.
4. Put the evidence where the claim is. dirigo-results/0.2.13-port/ holds the report, the chart, the raw JSON,
   the harnesses and scripts/make-chart.py, which recomputes every figure in the chart from that folder.

Corrections made to the original report (also listed in it): the errored column was the successful count; the
tok/s column was a mean of per-iteration samples, not throughput; the stock ref named the tag object instead of the
commit. Dropped: "12,288 of 12,288 slots pre-filled, 0 experts over PCIe", which no shipped file supports.

Validation

Passed:

• Numbers: BENCH=. python3 scripts/make-chart.py recomputes the chart from dirigo-results/0.2.13-port/'s own
  JSON; the printed deltas match the README table and the chart labels (−22.1 / −17.1 / −10.8 / −0.2 %; parity worst
  1.14 %).
• Citations: every figure in the README block traces to a file in the report folder; the upstream tag resolves
  (v0.2.13 annotated object fb57f747 → commit d2f0964); git diff v0.2.13 3512b4cc is 38 files, +5,062/−264,
  as stated.
• Links and anchors: 0 broken relative links in the README; the new #what-it-is-worth-… anchor and the
  dirigo-results/0.2.13-port/ links resolve.
• Rendering: GitHub's Markdown API returns the new block as an image plus a 4-column table; the SVG parses
  through ImageMagick and was reviewed visually for label collisions.
• Suite logs shipped under suites/ confirm 1,537 OK and 1,512 with one failure.

Failed:

none observed.

Not run:

• No new measurement. Nothing was benchmarked for this change: the data is the 2026-11-09 run, and only its
  arithmetic was redone. What stays unverified is whether the gap reproduces on a second session — the report says so
  in its limits.
• No build or serve, as this is documentation.

Limits

• One pass per arm, one card, one model, one quantization. The 2–4 % drift bound is quoted from the companion run,
  not re-measured here.
• The 1-stream throughput difference (+1 request in a 45 s window) is at the granularity limit and the README says
  so rather than counting it as a win.
• The claim covers unique-prompt traffic. For conversations the fork's router turns the cache back on and behaves
  like stock; that is stated on the front page.