← registerm/MAP-001.html
On file
D-Wave quantum supremacy claim
Tier 1 pick from FIND-001. Narrow, decidable, both sides published.
What it found
6positions
On hand

Nothing. It searches.

Environmentdeclared

Declared for this mission and copied when its deposit arrived. Nothing on file records what the session actually ran under — an environment is selected by name in the runner's own account, and a name that matches nothing falls through to their default without saying so.

Name
night-shift-map
Network access
Custom
Allowed domains
arxiv.org www.nature.com www.science.org pmc.ncbi.nlm.nih.gov journals.aps.org www.nber.org openreview.net
Setup script
no setup script
Environment variables
no variables
Brief151 lines
# MAP-001 — D-Wave quantum supremacy claim

Paste this whole thing. Nothing to fill in.

**Environment:** `night-shift-map`. The exact settings are on this mission's
page — the env file is the only place they live, so they cannot drift out of
sync with a copy written here.

---

## The job

D-Wave published a claim that its quantum annealer performed a simulation
beyond the reach of classical computers. Other groups disputed it. That
argument is public and unresolved.

Your job is not to decide who is right. It is to lay out the dispute so that
a reader can decide for themselves, and check you while doing it.

## What to produce

A document a smart non-specialist can follow. Assume no background in quantum
computing. Explain what needs explaining, briefly, where it comes up.

Cover:

**The claim.** What exactly was asserted — the specific problem, the specific
comparison, the specific sense in which classical methods were said to fall
short. Precision matters here: "quantum supremacy" is a headline, not a claim.
Find the actual sentence.

**Each challenge.** For every group that disputed it: who, what specifically
they showed, and what they did *not* claim to show. A paper that shows one
classical method matches the result is making a narrower claim than "the
original was wrong" — keep those distinct.

**Each response.** What D-Wave or its authors said back, and whether the reply
engaged the specific objection or reframed it.

**Stakes.** Who is employed by, funded by, or competing with whom. State it
factually and without insinuation — a stake is context, not an accusation, and
a paper is not wrong because its author has one.

**Where it stands now.** Has anything been settled? Did the exchange stop, or
is it live? Note the date of the most recent substantive contribution you can
find.

**What would settle it.** One paragraph. A specific benchmark, a specific
simulation, a specific comparison nobody has run. If nothing clean would
settle it, say so and explain why.

**What an outsider can and cannot check.** Which parts rest on public code and
data, and which rest on hardware, proprietary data, or resources a third party
cannot access. Be blunt — this is the most useful section for me.

## Sourcing rules

- Every claim about what someone said needs a citation: title, authors, year,
  link, and where in the document it appears (section, figure, page).
- **Open the page.** Do not cite from a search-result snippet. If a page will
  not load, say so explicitly and mark that citation as unverified rather than
  quietly using the snippet.
- Quote the sentence where each party states its position. One sentence is
  enough — do not reproduce passages.
- Where two sources conflict on a matter of fact (a date, a number, who did
  what), show both and say they conflict. Do not pick silently.
- If you cannot find a source for something you believe is true, leave it out.
- **"Blocked" and "paywalled" are different facts — say which.** A domain
  outside this environment's allowlist means you could not try. A domain that
  let you connect and then returned a paywall, login wall, or bot check means
  you tried and were refused. Both leave a gap in the record, but only the
  second tells the reader the source exists and is readable by someone else.
  For every source you could not read, the notes must say which of the two it
  was. Where a paywalled paper has a preprint, use the preprint and say you
  did.

## Tone

Neutral, and neutral is not mushy. "Both sides make good points" is a failure.
Say precisely what each side established, and precisely where the disagreement
actually sits — usually it is narrower than the public argument suggests.

If one side's position is substantially better supported by the public record,
say that plainly and show why. Neutrality means no stake in the outcome, not
refusing to report what the evidence shows.

## Output — two files, and both are required

**1. `output.md`** — the prose, as described above. Write it for a reader.
Structure it however reads best.

Then a section called **Notes on this run** — for me, not for a reader:
what you searched, what failed to load, which citations are unverified, what
you are unsure about, and anything that surprised you. Blunt.

**2. `positions.yaml`** — the same positions as structured data. One entry per
party per claim: a group that disputes two separate things gets two entries,
and two groups making the same claim get one entry each.

```yaml
positions_file:
  mission: MAP-001
  source: output.md
  count: <number of entries below>
positions:
  - id: P01
    party: <named person or group, as the source names them>
    claim: <one line, no hedging>
    stake: <employment, funding, or competition — factual, or "none found">
    sources:
      - url: <url>
        read: yes        # you opened this page and read the text you cite
      - url: <url>
        read: no         # you know it exists; you did not open it
```

**`read` is not a formality.** A URL you opened and a URL you merely know
exists are the same string, and listing one under `sources` implies you read
it. Say which. `read: yes` is checkable — an opened page leaves a fetch in
this session's transcript, which you do not write — so a `read: yes` with no
fetch behind it is a false record, and worth more scrutiny than an honest
`read: no`. Prefer citing what you read; where you must cite unread, say so
and the reader can weigh it.

**These must agree.** Every position in the prose appears in the YAML and vice
versa. The board counts entries in `positions.yaml` — it never parses your
prose, because a count derived from headings is a count that can silently be
wrong. If you can only produce one of the two files, produce neither and
deposit a finding explaining why.

An unmappable position is still a position: record it with the claim as stated
and `sources: []`, and say in the prose exactly what is missing.

## Where to put them

Push a branch to **`night-shift-network/inbox`** with both files inside a
directory named for this mission:

```
MAP-001/output.md
MAP-001/positions.yaml
```

The directory is what matters. A file at the root of the branch is not a
deposit and will not be collected — it will sit there looking delivered while
nothing has been.

The branch name does not matter and is deliberately not specified: the relay
reads every branch, so whichever branch your session is already on is fine.
Never delete or force-push a branch, yours or anyone else's; cleanup is
maintainer-side only.