[88plug]

H62r has been REFUTED on main since #343. The partner update, docs/intel.md and docs/platforms.md still called it pre-registered, and the technical report's limitations still said it had not run. The drift guard did not catch this because it reads only verdict words. This PR makes the guard catch it and brings the Intel docs up to date with main at e5f55b2 (release 0.1.94).

The guard (commit 1, test first)

tests/ledger_drift_check.py gets a "not run" form. Every id that comes before "not yet run", "not run yet" or "is/are pre-registered" in the same clause must be PENDING in the ledger. A clause ends at '.', ';' or '|', and a paragraph's line breaks do not end it; in a table row, the row's one id counts. tests/ledger_drift_check_test.py adds 14 cases: 8 that must pass and 6 that must drift. Before the doc fixes, the guard fails on main in 3 places:

• docs/platforms.md:252: H62r reads not yet run (not run) but EXPERIMENTS.md says REFUTED
• docs/intel/partner-update-2026-11.md:50: H62 reads not yet run (not run) but EXPERIMENTS.md says INCONCLUSIVE
• docs/intel/technical-report.md:152: H62r reads not yet run (not run) but EXPERIMENTS.md says REFUTED. The same line also flags H54a, H54b and H54c, because they share its clause.

A first version read whole sentences and also flagged three correct F4 sentences that name H1b or H14. The clause rule above does not. A pronoun after a ';' is out of its reach, as it is for the prose verdict form. intel.md's H62r sentence had that shape and is fixed by hand.

The docs (commit 2)

• H62r. Every doc now gives the result. At the GA tags, EAS's documented nri_reserved_cpu_list named the guest's 48 sibling vCPUs. Intel's install then finished in its KVM guest (failed=0), sized gemma-4-26b to 40 CPUs and placed EAT's sandbox router. In EAT's banking flow it delivered as many tasks within the turn budget as k3d-gpu's CPU stack: 21 of 24 each, paired difference 0.000 (CI -0.125 to +0.125).
  • The partner update states this as a result that helps EAT.
  • It also names the EAS finding behind H62. In a guest, EAS's topology probe counts the comma fields of thread_siblings_list and reads one thread per core (probe-node-topology.sh#L30-L31 at v1.2.0, read for this PR).
  • The EI cpu: auto draft in upstream-eat.md now says where its gap shows.
• wildct. All five rows stay PENDING, as on main.
  • H28w has run, and its result is in review in bench(wildct): H28w run on release 0.1.89, SUPPORTED #344. The docs say exactly that.
  • H57wa, H57wm, H57wb and H59w are pre-registered and not yet run.
  • docs/intel.md: the strict hybrid test first ran on hardware in H52w (CPU 0 and CPU 17). H18w backs E-core sandboxes alongside H18.
• Partner update, freshness.
  • A pin move also moves the test goldens that record the old value (pins: goldens move with their pins, and the per-site gaps that kept bot PRs red #328).
  • The runtime canary serves each engine in a plain container with the launcher's arguments, not in a pod. canary/run.sh uses docker run.
• Partner update, open items. Up to release 0.1.93, agent up did not serve through vLLM:
  • The 0.1.93 launcher names the Service vllm, leaves service links on and sends the warm-up through kubectl create --raw. I read this in the launcher.
  • agent: vLLM serves on k3d (no Service env links, JSON warm-up from inside the pod) #339 found the two causes on a B70 and fixed them. It merged while this PR's CI ran and ships in 0.1.94, whose launcher renders enableServiceLinks: false. The third commit says so. A full agent up run of a release on a B70 is not recorded yet.
  • The Gaudi path shares vllm_manifest.
  • docs: the vLLM agent has not served in any release up to 0.1.93 #359 covers the same status in the README and the other docs. This PR touches none of docs: the vLLM agent has not served in any release up to 0.1.93 #359's hunks.
• EAS feat: opt-in telemetry manifests (RAPL, P/E-core, Intel GPU, DCGM) #50 merged into EAS main on 2026-11-02, and it is not in v1.2.0 (gh api compare). The partner update and eas.md said it was open.
• README. H25w is in the Intel summary, H62r sits beside F5 in the EAT section, and H18w sits beside H18 in the sandbox table.

Versions were checked against the registries on 2026-11-07: EAS v1.2.0, enterprise-inference v1.1.0, EAT release-2.0.0, k3d-gpu 0.1.94. Every number on a claim line cites a SUPPORTED row or a primary source. The H62r numbers cite its run section, as the existing docs do.

Merge order

• This PR conflicts with bench(wildct): H28w run on release 0.1.89, SUPPORTED #344 (H28w) in the technical report's PENDING bullet and the partner update's wildct paragraph. Whichever lands second takes the other's lines and keeps H28w's verdict as the ledger then reads it.
• docs(intel): H25w row says the run did not test the power limit as the slowdown's cause #358 changes only the H25w row of the technical report, which this PR does not touch.

Checks run locally

• python3 tests/ledger_drift_check.py: 43 files agree with 83 ledger rows
• python3 tests/ledger_drift_check_test.py: 48 tests OK
• tests/claims_check.sh: 28 files clean. tests/claims_check_test.sh: 83 passed
• tests/docs_test.sh, with mkdocs from docs-build/requirements.txt: 63 passed
• tests/platforms_doc_test.sh: 195 passed. tests/pe_premise_check.sh: ok
• tests/image_pins_test.sh: 64 passed. It copies the guard.
• tests/ledger_freshness_test.py: 15 OK