orb(risk-control): the published guarantee rests on 231 backfilled labels; only 3 of 19 LIVE closes carry the confidence it needs

[JSONbored]

What the live data shows

Queried the production ledger on edge-nl-01:

origin	action	records	with aiConfidence
BACKFILLED (configDigest: backfill:unavailable)	close	231	231
live	close	19	3
live	merge	41	0
live	hold	15	1

The calibration corpus is 231 of 234 (98.7%) backfilled. Going forward the live pipeline attaches aiConfidence to only 3 of 19 closes (16%).

Why the live rate is so low

aiConfidence is populated only from an AI-judgment blocker — processors.ts ~3355 sets aiConfidence: aiJudgment?.confidence ?? null where aiJudgment is a blocker in AI_JUDGMENT_BLOCKER_CODES = {ai_consensus_defect, ai_review_split} (src/rules/advisory.ts ~174). But most real closes are not AI-judgment closes. From today's ledger the dominant reasons are CI is failing (...), missing before/after screenshot table, conflicts with the base branch, No linked issue detected, over the per-contributor open-item cap — all deterministic, all carrying aiConfidence: null, all therefore excluded from calibration.

loadCalibrationPairs keeps a label only if typeof record.aiConfidence === "number" (src/review/risk-control-wire.ts ~104), and coverage is n / sorted.length over that already-filtered set (risk-control.ts ~117).

The published-claim problem

The homepage renders closes ≥95% guaranteed at ${coveragePct}% coverage (apps/loopover-ui/src/components/site/proof-of-power-stats.tsx ~171). A reader parses "57.1% coverage" as 57.1% of ORB's closes. It actually means 57.1% of the AI-judgment sub-population of closes. If AI-judgment closes are ~16% of live closes, the true share of all closes covered is closer to 9%.

It is made worse by adjacency: the same sentence sits next to fleetAccuracy.coveragePct, which is a different quantity entirely — verdicts / (verdicts + holds) (src/orb/analytics.ts ~309). Two different denominators, one word, one sentence.

Verified NOT broken (checked, so nobody re-checks)

• No rename orphans. All decision_audit_labels.target_id values use the current JSONbored/* names; project matches the target_id prefix exactly on all 231.
• The label→record join lands on the right action. All 231 adjudicated close labels join to a record whose action is close — the feared hold/merge mis-join is not occurring today. (It remains a latent risk: the correlated subquery has no AND dr2.action = dal.verdict filter, risk-control-wire.ts ~91-94. Worth adding, mirroring the sampler's own decision IN ('merge','close') restriction at decision-audit.ts ~112.)
• The math reconciles. Global: totalPairs 226, nAtLambda 129, 129/226 = 0.5708 = the published 57.1%.

Fix

1. Either rescale before publishing (multiply by AI-judged-closes / all-closes) or rename the published field to something like aiJudgedCloseCoveragePct and state the sub-population in the UI string. Do not leave a bare percentage adjacent to a different coverage metric.
2. Add AND dr2.action = dal.verdict to the calibration join before the latent mis-join becomes real.
3. Surface the backfilled-vs-live split on the proof surface — a guarantee resting 98.7% on backfilled records should say so, and should tighten as live labels accrue.

Refs #8828, #8835, #9048.

[linear-code]

JSO-6256