# Contribute your research

> This wiki is the community's research home, and there is room in it for your work. Three ways to get it published, from a mailing-list post to a pull request, plus the small set of house rules that keep every page trustworthy.

- Canonical page (with interactive figures/demos): https://eternity2.dev/research/contribute/
- Updated: 2026-07-21

---
This wiki is not one person's blog with the door closed. It is meant to be the
community's research home: the place where nineteen years of Eternity II work
(records, methods, structural findings,
[dead ends](/research/build/dead-ends) included) gets written down, sourced,
and kept findable. Every page in [the lab](/research/lab) carries an author
byline and gathers on that researcher's [contributor
page](/research/people), today mostly
[Raphaël's](/research/people/raphael-anjou), because he is the one writing
things down, but the structure credits each contributor by name. Yours can sit
right beside his.

> **Nothing to publish yet?**
>
> Start by building. The [builder's toolkit](/research/build/toolkit) gets you to a running solver, and for a first target with a name to make, Brendan Owen's [10×10 set_2](/research/build/benchmarks#brendans-1010s-one-fell-one-is-still-standing) is the nearest unsolved board below the full puzzle. A result there is worth bringing back here.

There is already a precedent. The page on
[Blackwood's algorithm](/research/lab/experiments/joshua-blackwood/solver) is built on Jef
Bucas's notes and parameter study, republished with his explicit permission,
his figures, and his name on every one of them. That is the model: the work
stays yours, the wiki gives it a permanent, citable home.

## Three ways in

**1. Post it and flag it: the lightest path.** Share your finding where the
community already talks: the [mailing list](https://groups.io/g/eternity2) or
the [Discord server](https://discord.gg/Ny5xs3q8w). If you would like it on the
wiki, just say so in the post. Someone (usually Raphaël) will write it up as a
page, run it past you, and publish it with full credit. That is exactly how
the Blackwood page came to exist from Jef's notes. You never have to touch the
repository.

**2. Open an issue or a pull request.** The wiki is
[an open repository](https://github.com/raphael-anjou/eternity2), and a
research page is nothing more than one MDX file under
`web/content/research/`. Adding the file *is* the registration: the sidebar,
search, and sitemap pick it up automatically. Each page starts with a small
frontmatter block:

```yaml
title: Your finding, in one line
description: >-
  Two or three sentences that can stand alone in a search result.
kind: finding # or experiment, concept, reference...
updated: 2026-07-02
topics: [backtracking]
sources:
  - label: Hopfer's statement of the NS-1 condition (2022)
    url: https://groups.io/g/eternity2/message/10754
```

If the page is an **experiment** (a search run you measured), one more block is
required: the hardware it ran on. It is what lets a reader compare your result
to everyone else's, and the build refuses an experiment page without it.

```yaml
kind: experiment
hardware:
  cores: 1 # logical cores used; sum across nodes for a cluster
  cpu: "AMD Ryzen 9 7950X"
  ramGb: 64
  gpus: 0
  accelerator: none # none | gpu | quantum | fpga | tpu
  machine: "desktop, single box"
  wallClock: "10 × 60 s" # budget per run × repeats
  runs: 10
  seedPolicy: "randomized corner permutation per run"
  measured: true # true only for the standardized single-core bench
```

The page renders this as a spec card with one derived headline: **core-hours**
(cores × wall-clock hours), the true cost of the run. That single number is
what puts a one-core, one-minute search and a 400-core datacenter sweep in the
same table without one flattering the other. Set `measured: true` only for a
standardized single-core baseline (one core, a fixed time budget); a many-core
run is a `native run` and records its real kit and the best score it reached.

Not sure about the plumbing? Open an issue with your draft in plain markdown
and we will handle the rest. [Run it yourself](/research/build/run-it-yourself)
covers getting the site running locally if you want to preview your page.

**3. Share data and boards.** Not everything needs prose. A strong board, a
parameter sweep, a dataset from a long run: all of it is welcome. Every board
on this site is verifiable in the [viewer](/viewer), which speaks the
community's standard URL format natively, so anyone can check your result in
one click. Post the board or the data with a note on how it was produced, and
it can back a page or become one.

## The house rules

They exist for one reason: so that anyone landing on any page can trust what
they read.

- **Every claim links a source.** A mailing-list message, a repository, a
  paper: something a reader can follow.
- **Every number is reproducible or labelled for what it is.** Deterministic
  results come with a command that regenerates them exactly. Seeded,
  stochastic, or heavy computations say so plainly ("won't reproduce exactly",
  "~40 h on 8 cores") and ship the board they found so it can still be
  verified. A page's review status rides alongside on a separate tier: `report`
  for a technical write-up that is public but not yet reviewed, and `live` for a
  reviewed page that is cited and treated as settled (`draft` is the unpublished
  state you rarely see).
- **Every experiment says what it ran on.** A measured search is meaningless
  without its hardware, so an experiment page must carry the `hardware:` block
  above (cores, kit, time budget). The build enforces it. A score with no
  compute behind it is not a result anyone can compare.
- **French pages are written, not translated.** Each page exists in both
  languages, and the French version is real French prose, not a machine pass.
  If you only write one language, that is fine; a maintainer can arrange the
  translation of the other.
- **Your name stays on your work.** Credit callouts, source links, figure
  attributions: the Blackwood page shows what this looks like in practice.
  Nothing gets absorbed anonymously.

## What the wiki gives back

In exchange for meeting those rules, your work gets infrastructure that a
forum post never has: a stable page in the docs shell with sidebar, search and
breadcrumbs; placement in the [topic hubs](/research) so it is found by
theme, not just by date; a raw-markdown export of every page (append `.md` to
its URL) so it stays machine-readable; and a permanent URL other researchers
can cite, years from now and not just this week.

The puzzle has resisted everyone so far. The least we can do is make sure
nobody's progress against it gets lost.

## Related

- [Run it yourself](https://eternity2.dev/research/build/run-it-yourself) — The whole site, the engine, and every result in this section run from one repository. Here is how to get it going, rebuild the WebAssembly engine, and reproduce the numbers.
- [The builder's toolkit](https://eternity2.dev/research/build/toolkit) — A ready-to-use Rust starter kit for building your own Eternity II solver: score, generate boards with real colour balance, batch-generate with pinned clues, convert every format, benchmark, and a solve→sweep→compare iteration loop, so you write only the solver. Plus a one-line setup for coding agents, and a board generator right here in the browser.
- [Blackwood's solver, decoded and run here](https://eternity2.dev/research/lab/experiments/joshua-blackwood/solver) — Joshua Blackwood's record backtracker, decoded through Jef Bucas's notes (a colour quota schedule and a late-game mismatch allowance, tuned near-optimally), then built and run on my M1: left as published it flies to 248 of 256 pieces ignoring the clues; pin the five official clues and the same engine stalls near 45.