Developer mode

Developer mode is the original surface: everything the wizard produces shows up here, and you can author your own artifacts from scratch.

Switch to it via the avatar menu in the top-right → Switch to Developer mode.

The projects index

/projects lists every project in your org. Each row shows name, slug, description, age, and a quick-actions button. Click any to open the project shell.

The basic-mode brain index (/brains) shows the same underlying data with brain tiles instead of rows; both stay in sync.

The project shell

/projects/<id> is a left-sidebar nav with six tabs:

Tab	Route	What it does
Overview	/overview	Project metadata, README, key stats, recent activity
Priors	/priors	List, design, edit, inspect, fork priors
Models	/models	List, design, edit model architectures
Evals	/evals	List, design, edit evals
Runs	/runs	List training runs; compose new runs; open run details
Roadmap	/roadmap	Initiatives + progress notes (markdown-based)

The shell’s footer has a Delete project button — requires typing the project name to confirm.

If your project is a curated paper reproduction (its slug matches a known OSS study), the sidebar shows a green ● Reproducible study badge linking back to the original repo.

Priors

A prior is a Python function plus metadata. The Priors tab gives you three surfaces:

Priors list (/priors)

Each row: name, slug, kind, parameter summary, output summary, fork count, last-edited timestamp.

Buttons:

• + New from marketplace — opens the marketplace filtered to prior listings
• + New blank — drops to the raw YAML editor

Prior designer (/priors/new or /priors/<id>/edit)

The main authoring UI. Two tabs:

• Visual — family picker (regression / classification / time-series / etc.), block-style inputs for outputs + parameters, inline Python editor for the code field
• Math — render mathematical notation alongside the Python (for paper reproductions)

A marketplace banner at the top nudges you toward installing an existing prior rather than writing from scratch when one fits.

Prior inspector (/priors/<id>)

Read-only viewer with a built-in sampler. Shows:

• Parameter list (with current overrides)
• Output schema (variable names + tensor shapes)
• Parent prior (if forked) and fork count
• Citations
• Sample button — pick parameter overrides and a seed, click Sample, get a table of generated rows from POST /priors/<id>/sample

Useful for sanity-checking a prior’s output before wiring it into a run.

Prior edit (/priors/<id>/raw — legacy)

Thin wrapper around the full YAML/Python editor. Used for back-compat with older URLs. New work should go through the designer.

Models

A model is a blocks list + output heads + input shape. The Models tab:

Models list (/models)

Each row: name, slug, blocks summary (e.g. “tabular_embedder → transformer_encoder ×4 → scalar_head”), input shape, output heads.

Model designer (/models/new or /models/<id>/edit)

A canvas-style editor:

• Block library on the left (tabular_embedder, transformer_encoder, RMS norm, MLP, cross-attention, time encodings, heads…)
• Canvas in the middle — drag blocks in order
• Live validation — block compatibility checks happen as you compose
• YAML preview on the right
• Output head picker — pick which “skill” (number / classification / causal_graph / etc.) the model outputs

Evals

An eval is a scorer that runs after training. The Evals tab:

Evals list (/evals)

Each row: name, slug, metric, dataset reference, baselines.

Eval designer (/evals/new or /evals/<id>/edit)

Form for: name, metric (RMSE / AUROC / accuracy / etc., higher-is-better flag), dataset reference (e.g. registry:openml-credit-g@1.0.0), baselines (zero or more {name, score, source} entries).

The dataset is pulled from the per-org datasets registry (/datasets). If the dataset hasn’t been downloaded yet, the eval form prompts you to fetch it first.

Runs

A run is the training job — pulls prior + model + evals together with hyperparameters.

Runs list (/runs)

Each row: status pill (running / completed / failed / cancelled / draft), slug, prior + model used, hyperparams summary, started/finished timestamps.

Run composer (/runs/new)

Multi-section form for building a new run:

• Prior selection — grid of project priors; pick one or multi-select for Mixed / Ablation mode
• Model picker — pick from project models
• Eval selection — multi-select from project evals
• Hyperparams presets — Sanity / Standard / Long / Blank (custom)
• Compute target — local CPU or Vast.ai GPU
• Description — free-text run note

Save → creates a RunSpec (status: draft), navigates to the detail page. Execute there to actually train.

Run detail (/runs/<runId>)

The full per-run view:

• Status pill — running / completed / failed / cancelled / draft
• Definition cards — priors, model, evals, hyperparams (each expandable to raw JSON / YAML)
• Live progress — bar + step counter + loss curve while in-flight
• Logs — full streamed log (not just the last 8 lines like basic mode)
• Eval results — when complete, a table of metric scores vs baselines
• Try-it panel — same predict form as the basic brain page but with raw JSON request/response shown alongside

The advanced Try-it surface also exposes the sample-prior mode — calls POST /priors/<id>/sample to generate fresh synthetic rows, useful for testing without real data.

Roadmap

Markdown-based initiatives view. Each project ships with a seedInitiatives list from its template; you can add more inline. Each initiative has a title, version target, status (in_progress / done / etc.), tags, and a markdown body.

The old /initiatives URL redirects here.

When developer mode is worth it

• Authoring priors — basic mode can’t do this; developer is the only path
• Custom evals — you need a benchmark not in the curated set
• Fine-grained hyperparams — beyond the wizard’s recipe sliders
• Mixture training with custom prior bundles — the run composer’s Mixed mode
• Paper reproductions with divergence — fork a paper-backed brain, then edit the model/hyperparams without losing the readme provenance
• Using the CLI — pfnstudio push pushes local artifacts to a project (see API tokens)

For training your tenth brain on the same prior + same goals + different practise length, basic mode is fastest. Developer mode is for everything else.