charter
Version 1.0 — adopted 2026-08-19. Changes follow the RFC process.
Mission
MirrorQ exists to give the quantum computing community numbers it can trust: benchmark results that are blind (solved on fresh, private instances), reproducible (every score traces to an exact benchmark version and validator build), and governed in the open.
Scope
The service evaluates *solvers* — programs participants run on their own hardware — against *benchmarks* — families of generated task instances scored by a *validator*. The service layer is domain-neutral; every benchmark's domain logic lives in its validator behind the published validator contract. The service does not rank hardware and does not execute participant code.
Who operates it and who governs it
QudeLeap operates, funds, and hosts the service ("the operator"). Benchmarks, rules, and this charter are governed by the community through the RFC process and the Advisory Board. The operator holds one board seat and never the chair. Operator obligations are listed in OPERATOR_OBLIGATIONS.md.
What qualifies as a benchmark
A benchmark is accepted only if its instances are:
- Hard to precompute — there is no catalogue of all instances a participant could solve ahead of time;
- Cheap to verify — the validator scores a submission in far less time than solving it;
- Fresh per submission — every registration draws a new private seed; the seed and the answer key never leave the server;
- Deterministic given the seed — so a score can be replayed against the pinned validator build;
- Declared — metrics, direction of ranking, and task display fields are declared in the validator manifest, not inferred by the service.
These are the blind-instance principles checked by the conformance kit and by the design-validator review. An RFC proposing a benchmark must include a gaming analysis: how a participant could score well without solving the task, and why the design prevents it.
Benchmark lifecycle
Every benchmark carries the version of the validator that defines it and moves through four states:
| State | Meaning | Who moves it |
|---|---|---|
proposed | RFC open; no public leaderboard | proposer |
rc | Release candidate: public practice leaderboard, results not archived | board decision on the RFC |
stable | Results count, snapshots archive them, version is immutable | board decision after a practice period |
deprecated | No new submissions; history stays queryable and citable | RFC + board decision |
A stable benchmark version is immutable: any change to its tasks, generation, or scoring is a new version, recorded with a new changelog entry, and the service refuses to load a version whose definition has changed.
How decisions are made
- Rule changes, new benchmarks, retirements, and charter amendments are RFCs: public, commented for at least two weeks, decided by the board by simple majority with a quorum of half the seats, recorded in the RFC file.
- Operational decisions (deploys, incident response, capacity) belong to the operator and are reported, not voted.
- The operator may take emergency action (disable a benchmark, suspend an account) to protect integrity or security, and must open an RFC or an incident report within 7 days.
Archive snapshots
An archive snapshot is a frozen export of all published leaderboard entries for every stable benchmark version, together with benchmark definitions, provenance digests, baselines, and a hash manifest. The operator produces one on the first day of each quarter, starting with the first quarter after M2, under the rules in RFC-0001. The board signs off each snapshot before it is published under CC BY 4.0 with a permanent identifier. A published snapshot is a permanent scientific record; live leaderboards remain open and continue to change between snapshot dates.
Disputes
Any participant may dispute a score, a rule application, or an exclusion by opening an issue labelled dispute within 14 days of the event. The operator responds with the facts (provenance, logs) within 7 days; if the participant is not satisfied, the board decides, with any conflicted member recused. Decisions are published in the issue.
Conflicts of interest
See CONFLICT_OF_INTEREST.md. In short: the operator's own solvers may participate, flagged [operator], under identical rules; board members recuse themselves from decisions about benchmarks or submissions they have a stake in.
Amendments
This charter changes only by RFC. The current version and its history are in the repository.