The confirm gate

A cross-venue mapping must be confirmed by a person before it may back a benchmark constituent (INDEX-SPEC §3.1). This document states exactly what that gate covers, what it does not, and how a reader should interpret the counts published on every settlement row.

What the gate is asking

One question, and only one:

Are these two venue contracts the same question?

That is a judgement about a merge. Two venues word the same claim differently, settle it against different sources, and close it at different times; deciding that they are nonetheless one canonical event is the decision a person is being asked to make.

The gate applies to merges only

A single-venue constituent has no merge. There is no second contract, nothing was joined, and there is no proposition for a reviewer to accept or reject. The gate does not apply to it, and it is never counted as outstanding review.

This was not always the case, and the earlier reading was harmful rather than merely pedantic. Treating every unconfirmed mapping as provisional meant WETGRI published 92 of 92 provisional — awaiting human review every single day, for constituents that could never appear in the review queue, because the queue only ever contains cross-venue proposals. It reported a debt nobody could discharge, and it buried the number that actually mattered — how many genuine merges are still unreviewed — underneath it.

A disclosure a reader cannot act on does not make a benchmark more honest. It teaches them to skip the disclosure block, which is the one place a benchmark cannot afford to lose attention.

The three states

Every canonical mapping resolves to exactly one of these (lib/indices/graph.ts, confirmStateOf):

provisionalCount on a settlement row counts pending-merge only.

no-merge is not a silent upgrade

Single-venue admission remains fully disclosed. singleVenueCount rides on every settlement row, is published in the API and on every index page, and is stated in the daily close post. A single-venue constituent is priced by one venue and that fact is material — a reader must be able to see it.

What changed is only the label. It is disclosed as one venue priced this, which is true, instead of a review someone still owes, which was not.

What confirmation does and does not claim

Confirming a mapping asserts that the two contracts are the same question.

It does not assert that they settle on the same feed. The clearest case is the crypto ladders: Polymarket resolves ETH thresholds against Binance one-minute candles while Kalshi names its own source. Those feeds can disagree, and where they do, the disagreement is real.

That divergence is recorded on every confirmation and is exactly what WETFRAG measures. Confirming the mapping is what makes it measurable; assuming the feeds were identical would be the error.

How a confirmation is recorded

Through scripts/graph-confirm.ts, which writes to a committed file — so approving a mapping is a reviewable diff with a stored justification, not a database mutation nobody can audit.

The script refuses to bulk-approve:

• anything matched by title similarity rather than structural identity, and
• anything carrying a settlement-time or resolution-source mismatch flag.

Those are judgement calls and must be named individually with --id. Bulk approval is only defensible for structural matches, where the merge key is published on the entry and the decision is mechanically checkable rather than a matter of opinion.

Enforcement status

requireConfirmed is off during P1 bring-up. Turning it on would drop every unreviewed merge out of the index rather than disclosing it, and an index that silently narrows is worse than one that publishes its gaps. Unreviewed merges are therefore admitted and counted, and the count is published on the settlement row, in the API, and on the index page.

Changing this is a methodology change and follows methodology-change.md.