> ## Documentation Index > Fetch the complete documentation index at: https://docs.prbe.ai/llms.txt > Use this file to discover all available pages before exploring further. # Core concepts > Workspaces, projects, experiments, runs, artifacts, notes — what each one is for and how they nest. Probe has a small vocabulary. Most confusion comes from two words that sound interchangeable and are not: an **experiment** carries a question, a **run** carries an execution. Get that one right and the rest follows. ## The spine ```text theme={null} workspace a shelf — where projects are filed └── project a body of work, with a declared kind ├── experiment one question, and the runs that answer it │ ├── run group a sweep, an ensemble, a distributed job │ └── run one execution: metrics, files, spans, an outcome └── run a project-direct run — work with no hypothesis ``` Every level can carry artifacts, notes, tags and lineage edges. Nothing above a run is required for a run to exist. ## 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](/dashboard/workspaces.md). 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](/dashboard/workspaces.md#each-computers-workspace). ```bash theme={null} probe workspace list probe workspace create engineering probe workspace use engineering # this computer's new projects go here ``` ## 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 | What it means | Its page leads with | | - | - | - | | `training` | Work where model weights move | Metrics | | `evaluation` | Frozen-weight work — sweeps, ablations, evals. Formerly `inference` | Metrics | | `research` | Document-shaped investigation: lit reviews, design, theory | Papers | | `general` | Miscellaneous work — a real choice, not a fallback | Metrics | 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 kind `experiment`, 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 Runs relate to each other three ways. A **child** run nests under a parent. A **fork** continues a source run from a step, leaving the source untouched. A **group** collects peers — a sweep, an ensemble, the ranks of one distributed job. > [!NOTE] > > 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: | Anchor | Use it for | | - | - | | run | Checkpoints, outputs, logs, captured code | | experiment | Something that belongs to the question, not one execution | | project | Reference material, figures | | shared | The team's Shared folder, home of the team's datasets | 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](/tracking/datasets.md), and browse them on [Data](/dashboard/data.md). ## 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. On top of those there is one **team note**: a single shared document injected into every agent session on every machine. It is working memory for the whole team, and it has a render budget — a note past it reaches nobody. Markdown a person puts on the summary page (the `document` field) is kept as written when a recorder rewrites the rest. Runs have no summary page. > **[Summaries](/tracking/summaries.md)** > > Who writes them, and `probe summary checkout` / `push`. > **[Notes in full](/tracking/notes.md)** > > Checkout/push editing, sub-notes, the team note, and the rules for writing one. ## Session A coding-agent conversation. With [capture](/agents/capture.md) 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. ```bash theme={null} probe edge add --from run:abc --to artifact:ckpt-7 --type produced probe experiment edges EXPERIMENT_ID ``` ## Tags Free-form labels on projects, experiments, runs and papers. Filtering by several tags is **AND**, not OR. ```bash theme={null} probe run tag $RUN baseline reproduced probe run tag $RUN --remove reproduced probe run list --tag baseline --tag grpo ``` ## The switch For coding agents there is one more concept: the per-conversation switch. | State | Reads | Writes | | - | - | - | | `on` | yes | yes | | `read` | yes | no | | `off` | no | no | | `inline` | yes, by the agent itself | yes, by the agent itself | Where the [Probe daemon](/agents/daemon.md) 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](/agents/skills). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.