Benchmark governance

The confirm gate

What human confirmation covers — merges only — and how to read the provisional and single-venue counts.

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):

State Meaning Outstanding review?
confirmed A cross-venue merge a person accepted. No
pending-merge A cross-venue merge awaiting review. Yes
no-merge One contract, one venue. The gate does not apply. No

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.

The rest of the set
Methodology change & consultation
What counts as a material change, the 14-day consultation window, and why changes are prospective.
Data licence & rights
What the free tier grants, what attribution it requires, and what commercial use needs.
The loop architecture
The nine scheduled agents that cultivate indices, which one may publish, and the six mechanisms that assure accuracy.
Restatement policy
The three narrow conditions under which a published value may be corrected — and the many under which it may not.
Cessation & fallback
What happens when a benchmark cannot be computed, and why the history stays published forever.
Conflicts & the conflict wall
The wall between index operations and the trading circuit, plus standing disclosures.
Data-error playbook
Detection, triage, quarantine — and the commitment to disclose errors nobody noticed.
Complaints & challenges
How to challenge a value, a rule, or a constituent. No account required.
Settlement-reference licensing
What licensing a benchmark to settle against requires — and why publication alone does not grant it. Reading a value is free; referencing it in something that settles is not the same act.
Determination, disruption & cessation
Written for contracts rather than charts: who determines a final value, the disruption fallback ladder, and why a refusal is not a cessation.
The independent committee seat
The seven-part independence test, published before a candidate exists; the power to block rather than comment; and what the administrator may do while the seat is vacant.
Incident process
Who is paged, what they do, and what gets published when the machinery fails — as distinct from a wrong value, which is the data-error playbook.
Finding — the WETX coverage breach, August 2026
Why WETX refused for five consecutive days, the change that caused it, and what is still not established. Published because an availability figure without the incidents behind it is a number nobody can check.