fairness: the anchored ledger lives on the ORB, which is not publicly reachable — the public API serves an empty one

[JSONbored]

What

Running the new public verifier (#9723) against production returns two SKIPs, not passes:

PASS  Every eval-score record's recordDigest recomputes from its own contents   1 record(s) recomputed exactly
SKIP  Every corpusChecksum matches a downloadable corpus ...                    1 commitment(s) published, but no corresponding corpus is downloadable
SKIP  The current signed ledger checkpoint verifies offline ...                 no signed checkpoint published (anchor signing not configured, or the ledger is empty)
PASS  Published headline stats agree with the ledger-derived parity rollups     all-time handled=12882, windowed parity verdicts=0

Both SKIPs are facts about the deployment, not verifier limitations.

1. No signed checkpoint is published

/v1/public/decision-ledger/anchor-payload 404s. Per its handler that means either
LOOPOVER_LEDGER_ANCHOR_KEYS / LOOPOVER_LEDGER_ANCHOR_PRIVATE_KEY are unset, or the ledger tip is 0.

Consequence: the entire anchoring story (#9267 epic) is currently unverifiable by an outsider. The
machinery ships and is tested, but nothing in production is actually signed, so "the ledger's tip really
was X at time T" cannot be checked by anyone.

2. The one committed corpus is not downloadable

The single published eval-score record commits a corpusChecksum for ai_consensus_defect, but
/v1/public/eval-corpus?rule_id=ai_consensus_defect returns nothing usable — so the commitment covers
bytes no reader can obtain. Per #9805 a commitment is supposed to be OMITTED when the corpus is empty or
truncated, rather than published pointing at nothing; that omission does not appear to be happening here,
or the corpus read is failing separately.

Acceptance

• npx -p @loopover/mcp loopover-verify against production reports PASS (not SKIP) for the anchor
  checkpoint and corpus commitment claims.
• If a corpus genuinely cannot be published for a rule, that rule's record publishes no corpusChecksum
  at all, so the verifier reports it as absent rather than as an uncheckable commitment.

[linear-code]

JSO-6930

[JSONbored]

Correcting my own diagnosis — it is not a missing secret

I filed this saying anchoring was "not configured". That is wrong. Anchoring is configured and fully working — just not on the deployment the public verifier points at.

Verified directly on both:

	api.loopover.ai (Worker)	edge-nl-01 (ORB, 127.0.0.1:8787)
/decision-ledger/verify	totalCount: 0, tipSeq: 0	totalCount: 2190, ok: true
/decision-ledger/anchor-key	status: "unconfigured", 0 keys	key 6b6490126ad44b51 published
/decision-ledger/anchor-payload	404 anchor_signing_unconfigured	signed checkpoint at seq 2189
/decision-ledger/anchors	empty_ledger	real Rekor anchors (logIndex 46414223)
/decision-records/JSONbored/loopover/9941	404 not_found	—

So the ORB signs and anchors its ledger to Rekor on schedule. The Worker has no decision data at all.

The actual problem

The deployment that holds the anchored ledger is not publicly reachable, and the deployment that is publicly reachable has an empty ledger.

The ORB binds to 127.0.0.1:8787 with no reverse proxy, and reports upward to api.loopover.ai as its broker. Aggregate outcomes make the trip (that is where totals.handled = 12882 comes from); decision records and the ledger do not.

That makes the whole verifiability surface point somewhere it cannot work:

• /fairness and verify-this-review.mdx invite a reader to check the ledger at the public API.
• npx -p @loopover/mcp loopover-verify (cli(verify): one-command public verifier — replay every published claim, print PASS/FAIL #9723) defaults to that API and can only ever report SKIP there.
• The methodology page (docs(fairness): published methodology page — how outcome-confirmation, coverage, and intervals are computed #9725) describes an anchored ledger a reader cannot reach.

None of those are wrong about the mechanism — the anchoring genuinely works. They are wrong about where a stranger can see it.

What this needs is an architecture decision, not a secret

1. Expose the ORB's /v1/public/* surface (proxy + TLS) and point the verifier and docs at it. Smallest change to make the existing claim true; adds a public attack surface to the box that runs reviews.
2. Have ORBs report ledger tip + anchors upward on the existing broker channel, and serve them from the Worker. Keeps one public surface and scales to multiple ORBs; a real feature, and the Worker then republishes rather than holds the chain.
3. Restate the claim so the public surfaces say the ledger is verifiable by the operator, not by the public. Honest immediately, and gives up the property the epic was built for.

I have not touched anything on the server; it is exactly as it was.

Also worth noting

The corpus half of this issue stands and is unrelated: the Worker publishes a corpusChecksum for ai_consensus_defect while /v1/public/eval-corpus serves nothing for it.