# Scan OPEN results reconciliation This records the evidence reconciliation and restoration of the overlapping publication found on 8 September 2026. It is not a benchmark run or a fresh validation of historical measurements. The coordinating publisher restored the reviewed candidate to the shared TSV after preserving the overlapping data and checking its exact hash again. The patch matched the complete old file, so an intervening changed row would prevent replacement. Durable backup (nothing deleted): `/home/yann/libhft-bench-runs/scan-open-reconciliation-20260908-ybTBvL/` contains `overlapping-results-scan-open.tsv`, `overlapping-latency-matrix-scan.html`, `retained-v3-candidate.tsv`, and `provenance.json`. Both datasets remain recoverable. The HP publication and scratch worktree were not changed; their watchers were not stopped. ## Snapshots and ownership The examined shared file was `docs/bench/results-scan-open.tsv`, with 84 rows: 67 `ok`, 5 `fail`, 6 `nopool`, and 6 `noshard`. Its SHA-256 was: ```text 701931319d1b86b77ac8f97f77dc928742ec781e3692e1cd9b90f977a2d3b94a ``` The candidate is `/tmp/libhft-scan-reconcile-8vN8l2/results-scan-open.tsv`, SHA-256: ```text 70cce4cbfd462e1329d40ca09a4f3da0a7759ae2ded180111c80f391491d38dc ``` Its companion `provenance.json` in that directory records both paths/hashes, the seven input JSON hashes, and each supported cell's original evidence path and retained/withdrawn disposition. The candidate preserves the shared TSV's column header, row order, and 12 unsupported rows. The conflicting values belong to another session's scratch experiments; their evidence and a snapshot of the overlapping publication are preserved above. A bounded check for named publisher scripts did not match a process, but the coordinating agent subsequently identified still-live shell/tail publisher watchers (PIDs 3270279 and 3270320, parent 3193303). A negative script-name search therefore does not establish that publication has stopped. Those shell commands publish in the scratch worktree, not directly in the main repository; no live main-copy publisher was confirmed. The restoration was scoped to the main canonical scan OPEN file under the user's bench repair request, with both snapshots retained. A future uncoordinated main-copy job can still overwrite it and must not be mistaken for a new audited sitting. ## Exact source of the overlapping values The scratch experiment root is: ```text /tmp/claude-1000/-home-yann-code/e196e572-15ab-4fe1-95a7-22a279cee5a2/scratchpad ``` All 84 current rows are explained by the following `rows.csv` overlays. Counts refer to the last selected source after applying base single/mono/pool/shard CSVs, then the three `_rerun` CSVs, then `sx_fixed_open`. | Scratch subdirectory | Selected rows | CSV SHA-256 | | --- | ---: | --- | | `open_single` | 21 | `161f82c98fd38af07198f5dff90c9f640491e06fc2c762b5118a32ca070df380` | | `open_mono` | 14 | `ce0362831e0a47ed72e25cf966bfa82ad2eaced34402e6bee468e4b9b57f4d19` | | `open_mono_rerun` | 4 | `e84c00b5a3b29d6c0d661f2ae13d0b13e1d781648e4a82db9e8b1da86a72c26b` | | `sx_fixed_open` | 3 | `1e36eabe1b5d156c4733a56ed601d4fe572b433b250f125b797e61839e98e484` | | `open_pool` | 17 | `4851d5f749569495ec35d420384fd5ee9ed202cc7b82069d14a435bca15be514` | | `open_pool_rerun` | 4 | `40881657713a711f8b7e0782bd750b9ce99075d3c51ca87d295789fd3af45655` | | `open_shard` | 17 | `e43a43f751e89ccafcf334ee10e86a9c901d3f5072b96f88245fdd7f4f4d7536` | | `open_shard_rerun` | 4 | `ec91f2f68dc4e10b353d57385e222a22bc70b802cb2963e96bca5d103e00e04b` | The comparison checked flavour, transport, scenario, all four service latency fields, completed/requested sessions, and verdict-to-status mapping. The only numeric normalization needed was the failed .NET Native/VMA mono CSV's four `0.00` latency fields becoming blank. Unsupported verdict names were normalized to the TSV's lowercase spelling. This establishes the numeric source; it does not establish that the scratch runs satisfy current publication requirements. The scratch `run-mode-sweeps2.sh` explicitly runs the OPEN scenarios with `TPUT=50000 LOOP_MODE=open`. Its `sync-matrix-main.sh` contains a repeated copy from scratch `wt/docs/bench/results-*.tsv` and generated pages to the shared repository; `publish-matrix.sh` also copies those files. These scripts explain a possible publication route, not proof of which particular process performed the examined write. ### These are not interchangeable with retained v3 results For example, `open_mono_rerun/rows.csv:2` supplies the current C++/kernel/mono `p50_us=332373.58`. In the matching `cpp_kernel_1.log`: - Line 1 stamps standards **version 2**, `runs=3`, default `throughput=0`. - Line 2 records an explicit `--throughput 1562 --open-loop --sessions 8`. - Lines 17–22 report thousands of replies that did not name outstanding sends, including 57,680 unmatched replies, and explicitly say the pass's latencies are not trustworthy. - The result footer nevertheless says `status=pass`, `runs=3`, and `stability=INSUFFICIENT`. The matching C++/kernel/pool rerun logs contain the same explicit correlation warning. These particular latency values must not be republished as valid measurements, regardless of their old CSV's `SUSTAINED` verdict. This is direct log evidence, not an inference from unusually large latency values. The misleading `achieved_per_sec=6248` has an independently reproducible source: each of the four process aggregate footers reports `1562`, and the published field equals their sum. Each footer's target remains the **per-session** 1562, with eight sessions per process. Summing those four representative rates is neither a per-session rate nor the 32-session cell aggregate. It cannot be compared to the per-session target 1562 as if both fields had the same unit. Across all 71 supported cells that have canonical aggregate footers, the current achieved field equals this sum (single-process cells are unaffected by the sum itself). The remaining .NET Native/SocketXtreme mono cell has no such footer and its achieved field is blank. Do not repair this dataset merely by dividing rates by four: correlation, stability, affinity, and source provenance must also be respected. ## Retained v3 partition The following seven repository archives contain **60 distinct active records**. `open-sweep-scan.json` is excluded because it duplicates the archived R10 sitting. | Archive | Active records | Original sitting | | --- | ---: | --- | | `open-sweep-scan-single.json` | 8 | R4 | | `open-sweep-scan-mono.json` | 7 | R5 | | `open-sweep-scan-java-pool.json` | 3 | R6 | | `open-sweep-scan-r7.json` | 34 | R7 | | `open-sweep-scan-r8.json` | 1 | R8, explicit post-interruption collection | | `open-sweep-scan-r9.json` | 1 | R9 | | `open-sweep-scan-r10.json` | 6 | R10 | For 59 of those 60 records, the entire retained result object equals the corresponding result object in its original sitting's `sweep.json`, under `/home/yann/libhft-bench-runs/`. Every active record still has its referenced `run/rows.csv`. The source JSON hashes are preserved in the candidate's `provenance.json`; its per-cell entries avoid reconstructing provenance from a commit ID alone. The sittings have distinct source/artifact revisions. The R8 exception is documented, not silently recovered. Its driver was interrupted before reaping the completed Java/JNI/SocketXtreme mono harness, so the archive records `harness_exit: null`. Its exact evidence directory is: ```text /home/yann/libhft-bench-runs/open-v3-20260908-r8/mono/java-jni/socketxtreme/attempt-gh44phkd ``` `params-audit-collected.log` ends in a successful parameter audit and records OPEN, four processes × eight sessions, three measured runs, raw capture, and requested/effective/per-session rates of 50000/49984/1562. Its `run/rows.csv` records 32/32, `PARTIAL`, and service values 33.42/44.49/50.92/84.99, exactly as the retained object. The archive explicitly preserves the unknown harness exit, manual collection note, auditor path, and pinning-watch path. This review checks those retained records; it does not claim a new continuous pinning audit. The 60 active records comprise **10 `ok`, 49 `partial`, and one genuine `fail`**. The failure is R10 `java-jni/vma/pool`, with 16/32 delivery; its genuine measured partial service values remain failed evidence, not a successful capacity result. The other **12 supported cells** are all .NET Pure OPEN combinations: `kernel`, `onload`, and `vma`, each with `single`, `mono`, `pool`, and `shard`. Nine originals remain in R7's `withdrawn_results`, and three shard originals remain in R10's `withdrawn_results`. Their requested client affinity was not enforced. See [the affinity provenance review](DOTNET-OPEN-AFFINITY-REVIEW.md). This proves the missing enforcement, not their actual historical CPU placement or the numerical effect on latency. Historical closed/paced provenance remains undetermined by this review. The union of 60 active and 12 withdrawn keys exactly equals the 72 supported keys in `bench/load/load-bench-capabilities.tsv`: no duplicates, missing keys, extra keys, or active/withdrawn overlap. ## Restoration policy and candidate checks 1. Preserve the overlapping TSV and its source evidence before any replacement; coordinate with the other session's publishers. Do not delete or rewrite original sitting metadata, raw files, logs, or `withdrawn_results`. 2. Map all 60 active records to TSV fields exactly, retaining `partial`/`fail` qualifications and historical incomplete response-tail fields as recorded. 3. For the 12 withdrawn managed cells, use `fail`, preserve original 1/1 or 32/32 delivery counts, and blank every latency and rate field. Full delivery is diagnostic evidence and does not undo the affinity withdrawal. 4. Leave the 12 capability refusals unchanged. Do not fabricate results for unsupported combinations or reinterpret maximum throughput from target-rate measurements. 5. Review the isolated candidate, then let the coordinating publisher replace the shared TSV and regenerate both HTML pages. Rendering is not revalidation; a restoration is not a new measurement or a new uniform-staggered pacing run. The candidate assertions verify exact active-record field mappings, the complete 72-key supported partition, all managed blanks, unchanged unsupported rows, and final counts: **10 `ok`, 49 `partial`, 13 `fail`, 6 `nopool`, 6 `noshard`**. No measured samples, sinks, rates, or latency percentiles were synthesized. ## Subsequent response-tail recovery The Service/Response display now shows p50, p99, p99.9 and max for either metric. The old publication path retained only response p50/p99, although the original client logs also contained p99.9/max. Those two fields have been recovered for all 59 retained measured OPEN cells, not recalculated from service or rerun. The first 13 TSV columns, comments and line endings remain byte-identical to the restoration above; only `resp_p999_us` and `resp_max_us` were appended. All verdicts and archived sitting JSON records are unchanged. The other 25 rows have blank tails. Recovery rechecked complete canonical client results, mode, diagnostic, integrity and topology gates, and required exact agreement with the existing response heads, rates and retained archive records. Each tail is the maximum across the complete per-session/process percentile surface, not a pooled percentile. [The recovery record](response-tail-backfill-scan.json) contains all 59 source mappings, validator/archive/log hashes and the original backup location. Projecting the new TSV onto its original 13 columns reproduces SHA-256 `70cce4cbfd462e1329d40ca09a4f3da0a7759ae2ded180111c80f391491d38dc`. The extended TSV has SHA-256 `517695f6de335a31c41269764c2cdc6b5834379b1b52513c135c46907e2cec86`.