MOVE 37 → MOVE 42

The next move is an algorithm.

Move 37 answered a Go position with one coordinate no human expected. Move42 asks the same question in a larger action space: when the board is a requirement, can the move be a complete executable algorithm?

A requirement is a board. The contract defines legal play. The referee decides what worked.

01 · Go position19 × 19 stateboard + legal play
02 · Move 37Q16one coordinate
03 · Technical requirementfit(X, y)contract + permitted state
04 · Algorithm receiptexecute()complete method + consequence
Go position → Move 37 coordinate → technical requirement → executable algorithm receiptThesis: state → legal action → external consequence → preserved experience. Source: authored game thesis; Move 37 history is cited in the complete mirror.
01 / 9Same abstraction

01 · Same abstraction

Same abstraction. A larger action space.

Move 37 and Move42 share a formal pattern: a state receives a legal action, an external consequence determines what happened, and preserved experience changes later proposals.

Same abstraction. A larger action space.Two parallel paths map a Go position to one coordinate and a technical requirement to one executable algorithm, then converge on consequence and preserved experience.GO POSITIONstate under fixed rulesMOVE 37 · Q16one legal coordinateREQUIREMENTstate under a contractMOVE42complete executable algorithmconsequence → experience
Same abstraction. A larger action space.Source: Authored game thesis; Move 37 history and Move42 paper are cited in the complete mirror.

A requirement is a board. The contract defines legal play. The referee decides what worked.

state → legal action → external consequence → preserved experience.

The proposed output changes from an answer or score to an independently runnable method. The learning target is the distribution of later executable proposals across requirements.

What this supports

The analogy is structural, not a claim of identical search mechanics or equivalent empirical validation. Go supplies fixed semantics; each technical requirement defines a new game.

02 · Output type

The breakthrough is a different output type.

The move is not merely an answer, prediction, benchmark score, or research-loop suggestion. It is an independently runnable method that must complete the declared task.

The breakthrough is a different output type.A prediction and a benchmark score stop at an answer boundary while a complete method crosses parse, execution, and receipt gates as an independently runnable artifact.ANSWERterminal outputSCOREevaluation signalSUGGESTIONrequires more workINDEPENDENTLY RUNNABLE METHODPARSERUNRECEIPT
The breakthrough is a different output type.Source: Authored output-type thesis and active Move42 paper v1.

The proposed output changes from an answer or score to an independently runnable method. The learning target is the distribution of later executable proposals across requirements.

  • Not merely a better prediction.
  • Not merely a benchmark score.
  • Not merely a task-time research loop.
  • An independently runnable method.
What this supports

The precise thesis is a change in output type and learning target: propose an executable algorithm, observe its consequence, and improve later executable proposals.

03 · Where search occurs

Search now. Learn for later. Or combine both.

AutoResearch improves through proposal, execution, inspection, and retry on the current requirement. Move42 aims to improve the proposal distribution across requirements.

Search now. Learn for later. Or combine both.One lane loops through proposal, execution, inspection, and retry for the current requirement while another carries receipts across requirements into a later first executable proposal.CURRENT REQUIREMENTPROPOSE → EXECUTEinspect → retryACROSS REQUIREMENTSGAME AGAME BLATER PROPOSALhybrids can combine both lanes
Search now. Learn for later. Or combine both.Source: Authored system contrast; no comparative performance claim.

Where search occurs

Search now. Learn for later. Or combine both.

Current requirement

AutoResearch improves through a proposal–execution–inspection–retry loop on the current requirement.

Across requirements

Move42 aims to improve the proposal distribution across requirements, so the first executable move itself becomes learnable.

Hybrids remain possible; the distinction is where search occurs and what persists between tasks.

Evidence boundary. The current record does not measure superiority over research agents, task-time speedup, or an admitted prospective strict first move.

What this supports

Hybrids remain possible. This distinction describes where search occurs and what persists between tasks; the current record does not measure superiority, task-time speedup, or a prospective first move.

04 · Five-part blueprint

Five parts turn a requirement into a game.

The board defines permitted state, the move is executable, rules close shortcuts, the referee measures external consequence, and memory preserves successes and failures.

Five parts turn a requirement into a game.Five linked cards labeled board, move, rules, referee, and memory transform a requirement into an externally judged algorithm game with receipts.01BOARDSTATE02MOVEMETHOD03RULESLEGALITY04REFEREEOUTCOME05MEMORYRECEIPTSrequirement → executable move → consequence → experience
Five parts turn a requirement into a game.Source: Typed Move42 game blueprint.
  1. 01

    Board

    The requirement plus every permitted input, state transition, and resource boundary.

    Encode the requirement and permitted state before any proposal is made.
  2. 02

    Move

    One complete executable algorithm whose outputs can be independently reproduced.

    Define the runnable artifact, interface, and terminal outputs that count as a move.
  3. 03

    Rules

    The legality contract that rejects shortcuts, leakage, hidden state, and invalid resources.

    Close shortcut and leakage paths before play, then make every violation an explicit failure.
  4. 04

    Referee

    An external consequence-based evaluator that executes the move and records success or a named failure.

    Build the referee outside model self-assessment and bind its identity to every outcome.
  5. 05

    Memory

    Canonical success and failure receipts that can supervise later proposals across requirements.

    Preserve receipts, train later proposals, and separately freeze a true one-proposal prospective evaluation.
What this supports

A result is meaningful only when legality and consequence are outside model self-assessment and every terminal path leaves a canonical receipt.

05 · Current evidence

What if AI were a game?

Across 600 valid runs, jope-prime recorded 353 wins and 247 losses against TabFM Ensemble, a 58.8% result. Four-model Elo puts those comparisons on one common scale.

Four-model Elo ranking over 600 valid runsAn accessible final Elo dot chart and table rank jope-prime, TabPFN v3, TabFM Ensemble, and TabFM across exactly six hundred valid runs.90095010001050jope-prime1038.1TabPFN v31028.9TabFM Ensemble996.5TabFM936.6
Final computed Elo ranking
RankModelFinal Elo
1jope-prime1038.1
2TabPFN v31028.9
3TabFM Ensemble996.5
4TabFM936.6
TabFM, TabFM Ensemble, TabPFN v3, and jope-prime from the jAIn foundation family.Simulated learning path from 900 Elo; only the final four-model Elo ranking is computed from the 600 valid runs.Source: move42.elo-600.v1.
Valid runs
600
Wins
353
Losses
247
Result vs TabFM Ensemble
58.8%
What this supports

All six pairwise lower-RMSE comparisons per run feed the final ranking. The 58.8% result describes these 600 runs and is not a prospective universal success rate.

Valid performance runs600 valid runsThe complete corrected public performance set.Against TabFM Ensemble353 wins · 247 losses · 58.8%Jope-prime compared with TabFM Ensemble on every valid run.Final four-model Elojope-prime 1038.1 EloComputed from six pairwise lower-RMSE comparisons per valid run.

06 · Algorithmic moves

Different requirements call for different moves.

CPU, greenhouse, and spectrometer each receive a different complete algorithm under the same consequence-based referee, with exact programs and clocks preserved in the atlas.

Different requirements call for different moves.Three requirement cards for CPU, greenhouse, and spectrometer point to distinct executable programs and their recorded receipt outcomes without claiming causal explanations.CPUREQUIREMENTEXECUTABLE MOVE5.13× RECEIPT19.527s workflowGREENHOUSEREQUIREMENTEXECUTABLE MOVE3.40× RECEIPT19.614s workflowSPECTROMETERREQUIREMENTEXECUTABLE MOVE4373.89× RECEIPT100.180s workflow
Different requirements call for different moves.Source: Formal CPU, greenhouse, and spectrometer case-study receipts.
  • Cpu6.66× vs TabFM · 5.13× vs TabFM Ensemble · 11.34× vs TabPFN v3
  • Greenhouse3.40× vs TabFM · 4.66× vs TabFM Ensemble · 5.03× vs TabPFN v3
  • Spectrometer5,434.54× vs TabFM · 4,373.89× vs TabFM Ensemble · 4,530.65× vs TabPFN v3

Inspect the named within-dataset comparisons and verbatim programs.

What this supports

These focal cases are post-hoc descriptive records, not causal explanations or evidence of a future success frequency. Comparator wall-clock was not receipted.

07 · Memory

Every outcome can teach the next proposal.

The external referee records executable successes, losses, and named failures. Those receipts become stored supervision for a later challenger across requirements.

Interactive figure · ten recorded statesSource: active paper v1 and the receipt-based memory model; schematic labels are explanatory.

A ten-state learning loop preserves success and failure receipts, trains a later challenger after execution, and conditionally promotes it after frozen validation.

Static overview · all ten states

  1. 01
    Freeze parent

    Lock the retained policy and evaluator identities.

    Output · parent + evaluator receipt
  2. 02
    Select positions

    Choose recorded dataset contracts for this generation.

    Output · dataset contract set
  3. 03
    Propose programs

    Sample complete structured artifacts from the frozen parent.

    Output · program candidates
  4. 04
    Execute referee

    Parse, compile, fit, predict, and score; failures leave at named gates.

    Output · success + failure receipts
  5. 05
    Bind receipts

    Bind artifact, dataset, split, evaluator, resources, and outcome.

    Output · hash-bound receipts
  6. 06
    Store experience

    Retain measured scores, ranks, runtimes, stability, and failures.

    Output · immutable experience
  7. 07
    Train challenger

    Apply gradients only to the model from stored supervision.

    Output · candidate checkpoint
  8. 08
    Validate

    Run the frozen validation contract against parent and challenger.

    Output · comparison receipt
  9. 09
    Choose outcome

    Reject a regression or accept an eligible improvement.

    Output · retain / promote
  10. 10
    Start later

    A promoted challenger may become the frozen parent of a later generation.

    Output · new retained parent
Execution boundaryMeasurements cross as stored data. Gradients do not cross executed code.

Preserve receipts, train later proposals, and separately freeze a true one-proposal prospective evaluation.

What this supports

Gradients update the proposing model only after execution; they do not pass through arbitrary executed code. Frozen validation decides whether a later challenger is retained.

08 · What does this mean?

The game pattern can reach beyond tables.

Compiler, control, experimental, and scientific-design games illustrate how requirements could become executable moves under domain-specific rules and referees.

The game pattern can reach beyond tables.Four vision cards map compiler, control, experimental, and scientific-design requirements to executable moves and domain-specific referees.VISION · COMPILER GAMEboard → move → refereeNOT A CURRENT FINDINGVISION · CONTROL GAMEboard → move → refereeNOT A CURRENT FINDINGVISION · EXPERIMENTAL GAMEboard → move → refereeNOT A CURRENT FINDINGVISION · SCIENTIFIC-DESIGN GAMEboard → move → refereeNOT A CURRENT FINDING
The game pattern can reach beyond tables.Source: Typed forward-looking implication records; all are vision, not findings.

Vision · Compiler game

Board
A source program, target semantics, architecture, and optimization contract.
Move
A complete transformation or optimization algorithm that produces executable output.
Referee
Correctness suites, resource limits, and consequence-based performance measurements.

A design horizon, not a finding of the current regression study.

Vision · Control game

Board
A control requirement, observable plant state, hard constraints, and permitted actuators.
Move
A complete control algorithm that can be executed against the declared interface.
Referee
Constraint violations, stability, resource use, and measured physical consequence.

A design horizon, not evidence of autonomous control performance.

Vision · Experimental game

Board
An apparatus, measurement protocol, budget, safety envelope, and experimental objective.
Move
A complete executable experiment schedule and analysis method.
Referee
Predeclared measurements, explicit failure outcomes, and independently preserved receipts.

A design horizon, not an experimental result reported here.

Vision · Scientific-design game

Board
A scientific question, admissible evidence, interventions, and falsification criteria.
Move
A complete executable design for collecting and analyzing the next evidence.
Referee
Preregistered consequence tests that can reject as well as support the proposed method.

A design horizon, not a claim of causal or scientific discovery.

What this supports

Every implication on this page is labeled vision. None is a finding of the current regression study, a safety claim, or evidence of performance in those domains.

09 · Generation scale and limits

Generation scale is not performance evidence.

317,156,096 generated algorithms describe the search-generation scale. The public performance result remains exactly 600 valid runs.

Generation scale is not performance evidence.Two separated records show 317,156,096 generated algorithms as generation scale and 600 valid runs as the only public performance set.GENERATION SCALE317,156,096 GENERATED ALGORITHMSPERFORMANCE EVIDENCE IS SEPARATE600 VALID RUNS
Generation scale is not performance evidence.Source: Hash-bound algorithm-generation receipt and the separate 600-run Elo receipt.

Generation scale

317,156,096 generated algorithms

This generation-scale receipt is separate from the performance evidence.

Performance evidence

600 valid runs

The 58.8% result and final four-model Elo ranking use only these runs.

Boundary

Generation is not evaluation

No additional run, game, dataset, file, finalist, cohort, or campaign total is a public performance claim.

What this supports

Generated algorithms are proposals, not additional performance runs. The 600-run result remains historical and does not establish a prospective universal success rate.

Algorithm generation scale317,156,096 generated algorithmsA separate generation-scale fact, not a performance-run count.Valid performance runs600 valid runsThe complete corrected public performance set.

Keep reading

Choose the depth you need.

Evidence claim

Claim detail

Status
Source
Pointer
Limitation

Open the normalized ledger