Skip to content

Search is only available in production builds. Try building and previewing the site to test it out locally.

Paper reproductions

PFN Studio’s wizard has two routes through the build pipeline:

  1. Wizard-derived route — model spec, hyperparameters, and evals come from your wizard choices (recipe size, goals, etc.). This is what runs for capability mixes and demo priors.
  2. Paper-pinned route — when you select exactly one paper-backed prior, the wizard reproduces the paper’s published study verbatim. The recipe sliders are ignored.

This page explains when each route fires, why the distinction matters, and how to override it.

When the paper-pinned route fires

The trigger:

wrappers.length === 1 && wrappers[0].paperBacked

So: single prior + paper-backed.

Examples that pin to paper:

Capability selectionPrior chosenPaper-pinned?
Predict a numberpfns-reference✅ Müller 2022
Forecast forwardtabpfn-ts✅ Hoo 2024
Forecast forward + Pick next experimentifbo✅ Rakotoarison 2024
Forecast forward + Show confidencetabpfn-ts✅ Hoo 2024
Predict a number + Forecast forwardmixture (refused — different shapes)n/a
Sort into categories (coming-soon)two-moons demo❌ demo only

Multi-prior mixtures and demo-only selections fall through to the wizard-derived route.

What gets pinned to the paper

When the paper-pinned route fires, everything that affects the trained brain comes from the paper itself:

  • Prior parameter overrides — e.g. TabPFN-TS uses num_lags: 8, series_len: 96
  • Model architecture — depth, width, blocks, output heads — verbatim
  • Eval suite — the paper’s own benchmarks
  • Hyperparameters — learning rate, batch size, step count, seed
  • Readme — the paper’s own preamble, so the project page tells the reproduction story, not the wizard story

What you keep choosing

Even on the paper-pinned route:

  • Project name — comes from your capability selection (“Forecast forward”)
  • Project description — derived from capabilities, not the paper’s text
  • Practise length — Quick / Standard / Long / Marathon as you picked
  • Compute target — local CPU vs Vast.ai GPU as you picked

The paper-pinned route doesn’t lock you into the paper’s compute target either. If the paper ran Marathon on an A100 but you only want to smoke-test it for 30 seconds, Quick taste still works — you just get fewer training steps.

Why this exists

The wizard’s recipe sliders (Quick / Steady / Deep, depth 2 / 3 / 6) are friendly defaults for building a new brain. For reproducing a paper, those defaults silently diverge from the paper’s actual architecture. Two examples:

  • LC-PFN was trained at d=128, depth=4, heads=4 for 50k steps with a specific cosine schedule. The wizard’s Steady defaults to d=64, depth=3, heads=4 — close but not the same.
  • ifBO was trained on a temporal_tf contract with engineered freeze-thaw context. The wizard’s default architecture doesn’t include the freeze-thaw block.

Letting the wizard pick those values would mean a “reproduction” that quietly doesn’t reproduce. The paper-pinned route makes the choice explicit: when you pick a paper-backed prior alone, you get the paper.

Diverging from the paper

Two paths:

1. Add a second capability

Picking more than one capability — say Forecast forward + Pick next experiment + Show confidence — drops you back to the wizard-derived route (or to a different paper if a single prior covers all three).

2. Switch to developer mode

Fork the brain, then edit the model spec or hyperparams directly. The forked project’s model is yours to change. See Developer mode.

This is the right path if you want to start from the paper’s architecture and then tweak it — common workflow for ablations or scale-ups.

Reading the project after submit

A paper-pinned project’s README starts with the paper’s own preamble, not the wizard’s generic “your brain practises on…” text. That’s the easiest visual signal that the project is on the paper-pinned route. The basic-mode brain page shows the same capability chips regardless — those come from the prior’s tags, not from the route choice.

Why no “pin to paper” toggle

We considered a toggle. The downside: it makes the user explicitly choose between “recipe defaults” and “paper defaults” every time. The signal we want is intent“I want this paper” is exactly what “single paper-backed prior selected” already encodes. So the route is derived from intent, not added as a separate switch.