# Site-thread corrections and measurements — OrbitalProof (networks)

Written by the site thread on 2026-09-04 while merging the f2, f3 and f4 content packages onto one
page. Every lane sentence on this site is rendered unedited. Some of those sentences were true when
their lane wrote them and are made false by this site's own existence: a lane that says its evidence
is unreachable is contradicted by a page that serves that evidence. Rather than edit a lane's prose,
each such row is followed on the page by a correction row that cites this file, and the finding is
routed back to the lane.

Each section below is the receipt for one correction row. The measurements were run on this machine
on 2026-09-04; the commands are given so they can be re-run.

## 1 — f3's evidence is now readable here

f3 wrote: "The repository behind every claim on this page is PRIVATE. An unauthenticated request
returns 404, so a stranger can read this page and the public tools, and none of the register, the
sealed bars or the corrections."

Still true: the repository is private and an unauthenticated request returns 404.
No longer true of the cited evidence: this site serves **46** files from that repository as
receipts, extracted from commit `0eaf50e09a30855103f3e5fcdc8683a9f30f65a4`, among them the sealed
bars under `artifacts/prereg/` and the corrections in `dataroom/STALE_CLAIMS.md`.
Count: `find receipts/f3 -type f | wc -l`.

## 2 — there is now a company name and a domain

f3 wrote: "There is no company, no domain and no organisation behind any of this. Nothing on this
page is a product, a price, or an offer."

No longer true: this site is OrbitalProof and the domain `orbitalproof.com` is registered.
`curl -sS https://rdap.verisign.com/com/v1/domain/orbitalproof.com` returns `ORBITALPROOF.COM` with
`registration 2026-09-05T00:54:08Z`; `dig +short orbitalproof.com NS` returns `ns1.vercel-dns.com.`
and `ns2.vercel-dns.com.`.
Still true, and measured on 2026-09-04: no organisation exists. `curl -o /dev/null -w '%{http_code}'
https://github.com/orbitalproof` returns 404 and `https://huggingface.co/orbitalproof` returns 404.
Still true: nothing on this page is a product, a price, or an offer.

## 3 — f4's evidence is now readable here

f4 wrote: "nothing produced in this program is reachable by a reader, and the public surface is the
eleven repositories and two datasets frozen on 2026-08-18."

No longer true of the cited evidence: this site serves **68** files from that repository as
receipts, extracted from commit `8c2ab57246dcd3c394f124838bdba47cbc74d4ff`.
Count: `find receipts/f4 -type f | wc -l`.
Still true: the repository is private, and the eleven public repositories and two datasets remain
the whole of its public surface anywhere other than this page.

## 4 — the verifier on this page is not this site's

The checker in the Stranger Verifier section is f2's browser verifier. The program assigned the
implementation to f2 (S08 ownership O3, decided on the measured cross-verification matrix) and
placed its home at the holding company rather than at any subsidiary (D59), because five sites embed
the same implementation. This site embeds it and claims no credit for it. f2's artifact row for the
bundle renders on the holding company's site and not here. Its repository does not exist yet, so no
link to it is offered; `https://github.com/orbitalproof` returns 404, measured 2026-09-04.

## 5 — two f3 artifact rows point at the wrong verifier

f3's `protocol-bench` command-line row says "The scorer is the stranger check named in the verifier
section", and its PCAR/1 bundle row says "It is stronger than the check named above". Both sentences
were written for a page whose verifier section carried f3's own scorer. On this merged page that
section carries f2's checker instead, so both point at the wrong check. f3's prose is rendered
unedited and the mismatch is recorded here and routed to the lane. f3's own offline check is not
rendered anywhere on this page: the template carries one verifier, and this site's is f2's.

## 6 — the seal audit, and why the page no longer opens on a violated seal

Added 2026-09-05 after the cross-site QA thread found the headline resting on a seal adjudicated
`VIOLATED`. All 16 public indictment rows were audited against the receipts they cite, not sampled.

| seal-verify receipt served | adjudication |
|---|---|
| `f2/out/seal_verify_bpf_upstream_2026-09.txt` | HELD |
| `f2/out/seal_verify_real_vvc_inloop_2026-09.txt` | HELD |
| `f2/out/seal_verify_cve_2025_guards_2026-09.txt` | **VIOLATED** |
| `f2/out/seal_verify_bpf_repin_2026-09.txt` | **VIOLATED** |
| `f2/out/seal_verify_browser_verifier_2026-09.txt` | **VIOLATED** |
| `f2/out/seal_verify_glm_inference_floor_2026-09.txt` | **VIOLATED** |

Of the 16 indictment rows, **two** cite a receipt that adjudicates `VIOLATED`: the libxml2/OpenSSL
CVE-guard row and the Cilium/Katran re-pin row. The other 14 do not. The remaining two violated
receipts above are cited by envelope and negative-result rows, where the miss is the point.

`VIOLATED` in these receipts means *at least one sealed key missed*, not that the result is false.
The CVE-guard seal has fourteen keys: thirteen held and one missed, and the missed one is
`bar_both_fix_refs_verified_online`, an in-run web call that came back rate-limited — not a proof
key. The re-pin seal has eight: seven held and the miss was this lane's own bar reading the wrong
field of the pins block. Both are named in the rows themselves, and by f2's own rule a git-prior
seal with any missed key forfeits the third-party-with-a-bar label.

That rule is why the page no longer opens on it. A `⊢ sealed bar` badge over a number whose seal was
adjudicated violated asserts a grading this estate's own standard says was forfeited. Two seals here
were re-run and held on the second attempt — `seal_verify_browser_verifier_2026-09b.txt` and
`seal_verify_glm_inference_floor_2026-09b.txt` — and the CVE-guard seal has no such re-run. It was
not re-sealed and not re-run for this page.

## 7 — what opens the page instead

The opening result is now f3's protocol-bench run: a bar hashed into git before the model weights
were fetched, three sealed predictions and **all three held**
(`predictions_and_outcomes[*].held = true`), with a fabricated-trace negative control run first that
fired as a control should (`negative_control.fired = true`, balanced accuracy 0.5, zero valid
counterexamples). Receipt `f3/artifacts/backends/protocol_bench_model_run.json`; the seal is
`f3/artifacts/prereg/protocol_bench_qwen_bar.json`, recorded at commit
`1d5b14cbdedbad31eca050c71613f609396a83c3`.

It is also on this company's subject — fifteen published IEEE 802.11 and 3GPP procedures — where the
CVE-guard result is about two C libraries. The f2 result stays on the page as an indictment row with
its violated seal linked; it stops being the headline, and nothing is dropped.

## 8 — machine paths in served receipts

The template refuses to publish a file naming the machine that built it. Seven served files carried
`/Users/<name>`. Three are artifacts that captured a local path as tool output, and they are now
sealed — path and sha256 publish, bytes do not — and routed to their lanes to fix at the producer:
`f4/artifacts/native/oss_verifiers_ci.json`, `f3/artifacts/prereg/s08_scope_defaults_estate.json`
and `f2/out/negative_controls_2026-09-02.txt`.

The other four are a different thing: a lane quoting the very path it is retracting or confessing.
f3's retraction ledger marks its own occurrences `PD-OK: quotes the claim being adjudicated`, and
f4's confession names the path as item 4 of what its own check caught. Those cannot be scrubbed
without deleting the evidence of the defect, and the confession is rendered verbatim by rule. They
are reported to the template thread and to f3 and f4, who can write `/Users/<name>` and lose nothing.

## 9 — two receipts are published as a hash, not as bytes

Added 2026-09-05 under the orchestrator's R7: where a private string sits inside bytes a hash covers,
the file is sealed — path and sha256 publish, bytes do not — and the row that cites it says so.

`f3/artifacts/prereg/s08_scope_defaults_estate.json` is the preregistration behind the estate-scanner
indictment. Its text records the absolute roots the scan walked, which names the machine that ran it,
and that text sits inside the region the seal's own sha256 covers. Redacting it would void the seal
rather than protect anything, so the seal stays intact and the bytes stay off this site. The row
carries that sentence itself.

`f4/STALE_CLAIMS.md` is f4's retraction ledger and **57 rows on this page cite it**. f4 redacted one of
its two machine paths at commit `6a8f22ab` and left the other: line 163 quotes the path a quarantined
fabricated generator writes. It is sealed until f4 redacts that line as it redacted the first, at
which point the seal lifts and 57 rows go back to offering bytes. Until then they offer a hash, which
is a weaker offer, and this row exists so that nobody has to discover it by clicking.