The spine
Workspace
A place to file projects. Not an ownership boundary — every member of the team reads every workspace, and that is a product decision, not an omission. What a workspace can restrict is who may edit what is filed in it, through access groups and writer lists. Teams use workspaces the way you would use folders:engineering, wandb-imports, one per external integration. Connecting Weights & Biases or Benchling creates a dedicated workspace and asks you what to call it.
Each computer files its new projects into one workspace, chosen in the setup wizard. On a team with several workspaces and none chosen, a new project is refused rather than guessed. See each computer’s workspace.
Project
The top of the data model, and the unit a person thinks in. A project declares a kind, from a closed vocabulary, and the kind decides how its dashboard page is laid out:
Kind reaches the project page only. It never restructures an experiment or a run.
Projects nest: a phase of a bigger effort is a subproject (
probe project create --parent), never a new top-level sibling. Projects can also reference each other laterally — use that when a review informed a training run, or two efforts share a method, where a parent relationship would claim something false.
Experiment
One question, and the runs that answer it. It is stored as a project of kindexperiment, filed under its parent project. The question field is the point of the entity; if you cannot write one, you probably want a project-direct run instead.
The question is first-write-wins: reopening an experiment never rewrites it. That is deliberate — an experiment whose question drifts to match its results has stopped being an experiment.
An experiment can be frozen into an immutable version that pins its current run set (probe experiment freeze), which is what you cite when the numbers go into a paper or a decision.
Run
One execution. It holds:- metric series, each identified by
(kind, key, dimensions) - artifacts — the files it read and produced
- spans — a trajectory: rollouts, turns, tool calls
- a code snapshot — what was on disk when it started
- lifecycle:
running→completed/failed/canceled, plus a heartbeat so a crashed run is reaped rather than left open forever
Creation rules differ by surface on purpose. The SDK creates projects, experiments and runs freely, because a training script should not fail on a missing row. On the CLI,
probe run start never creates — the slug is hand-typed every time, and that is where typos come from. A near-miss of an existing slug is refused, not created.Artifact
A file, anchored somewhere. The anchor is what makes artifacts useful rather than a dumping ground:
Workspaces hold projects only. Files filed straight on a workspace were retired in October 2026.
Artifacts are content-addressed and deduplicated by SHA-256, and they version: appending the next version keeps the chain. Versions never supersede by name — two artifacts with the same name coexist and are ordered by creation.
Bytes do not have to leave your infrastructure: an artifact can be a reference to an object you keep in your own bucket, with the pointer and checksum recorded in Probe.
Datasets, sources and checkpoints
The team’s data catalog. A source is where outside data came from (a Hub dataset, a bucket, a URL). A dataset is a team-wide name with versions (dataset:c4-clean@3), each made by a run and linked to what it came from. A run says what it used, with a role (train, eval, init, …). Every checkpoint remembers what its run had trained on when it was saved. Together they answer “what did this model train on, and how was that data made?” See Datasets, and browse them on Data.
Prose: three homes, deliberately
This is the distinction people get wrong most often.description
The short identity line. One or two sentences. Shown everywhere the entity is listed.
Summary
A project’s or experiment’s teammate-facing page, shown as Summary on the dashboard. The recorders write it as work happens: the Probe daemon’s writer, or an agent working inline.
notes
The operational briefing agents read and write. Supports append, titled sub-notes, and merge-on-push editing.
document field) is kept as written when a recorder rewrites the rest. Runs have no summary page.
Summaries
Who writes them, and
probe summary checkout / push.Notes in full
Checkout/push editing, sub-notes, the team note, and the rules for writing one.
Session
A coding-agent conversation. With capture on, sessions stream into the knowledgebase and become searchable: the prompts, the replies, and the shell commands. A session can also be attributed to a run, which is how “why was this run launched” stays answerable.Lineage
Edges between entities — run to run, run to artifact, artifact version to artifact version, paper to paper. Lineage is what lets you ask what produced a checkpoint, or which paper led to which.Tags
Free-form labels on projects, experiments, runs and papers. Filtering by several tags is AND, not OR.The switch
For coding agents there is one more concept: the per-conversation switch.
Where the Probe daemon records for an agent,
on and read mean the daemon reads and records; inline stops the daemon and the agent reads and writes Probe itself.
Only the researcher moves it. An agent invoking the skill loads guidance and never changes the state. See the /probe skill.