> ## 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. # Projects and experiments > Create, organise, tag, nest, freeze and delete the structures runs live in. ## Projects ```bash theme={null} probe project create folding --kind training probe project list # in the active workspace probe project list --all # across every workspace probe project get folding probe project use folding # make it the default for run start and friends ``` A new top-level project is filed in this computer's workspace: the one `probe workspace use` set (the setup wizard asks for it), `PROBE_WORKSPACE`, or `--workspace` for one call. On a team with several workspaces and none set, the create is refused rather than guessed. A subproject always lives in its parent's workspace. A project declares a **kind** from a closed vocabulary — `training`, `evaluation`, `research`, `general`. The kind decides how the project's page is laid out, and nothing else; it never restructures an experiment or a run. | Kind | Use it for | | - | - | | `training` | Work where model weights move | | `evaluation` | Frozen-weight work: sweeps, ablations, evaluation runs | | `research` | Document-shaped investigation — lit reviews, design, theory. Shows its papers in the Overview | | `general` | Miscellaneous work. A real declared choice, not a fallback | > [!NOTE] > > A sweep over a frozen model is an **experiment inside an evaluation project**, not a project of its own. Reaching for a new project every time is how a workspace becomes unreadable. `inference` is the old name of `evaluation`. An older client that still sends `inference` gets a project stored as `evaluation`. ### Display fields ```bash theme={null} probe project set folding --name "Protein folding" --description "DockQ studies" probe project set folding --add-tag dockq --remove-tag draft ``` ### The Overview page Every project and experiment has an **Overview**: the page teammates read to catch up. The agents that record your sessions write it. See [summaries](/tracking/summaries.md) for who writes it, how to edit it with `probe summary checkout` and `push`, and how a block of your own stays put. `--summary` writes the project's own block on that page, which no agent may rewrite: ```bash theme={null} probe project get folding --fields document # the block, as the page holds it now probe project set folding --summary @PROJECT.md ``` `--summary` replaces **that whole block**, so read it first. The read is rendered back from the page, so check that it *contains* what you meant rather than matching your file byte for byte. A line containing only `[README](https://github.com/owner/repo)` embeds that repository's README at that point. ### Nesting and lateral links ```bash theme={null} probe project create folding-phase2 --kind training --parent folding # a SUBPROJECT probe project move folding-phase2 --parent folding # or move one later probe project move folding-phase2 --top-level probe project move folding-phase2 --workspace engineering ``` A phase of a bigger effort is a subproject of it — never a new top-level sibling. A workspace move applies to a top-level project; a subproject follows its root. When the relation is not containment, use a **reference** instead: ```bash theme={null} probe project reference add lit-review --to folding ``` Use it when a review informed a training run, or two efforts share a method — the relation `--parent` would claim wrongly. It is directed: adding A→B does not add B→A. ### Attached code ```bash theme={null} probe project code list folding probe project code attach folding owner/name --reason "the runs' code snapshots name this remote" probe commits folding # one page of the commit timeline, newest first ``` The timeline is read **through** GitHub by the backend. Nothing is mirrored, so attaching is cheap and detaching loses nothing. Attaching grants no access: the repository must be public or covered by the team's GitHub App installation. ### Who worked on it ```bash theme={null} probe project contributors folding ``` ## Experiments An experiment is one question and the runs that answer it. ```bash theme={null} probe experiment create dockq --question "does temperature 0.7 beat 1.0 on DockQ?" --project folding probe experiment list --project folding probe experiment get dockq probe experiment set dockq --name "DockQ sweep" probe experiment set dockq --conclusion "Yes: 0.7 scores 0.71 DockQ against 0.64 at 1.0, over 3 seeds each" ``` > [!WARNING] > > Reopening an experiment never rewrites its question: `probe.init(question=...)` on an experiment that exists leaves the question alone. `probe experiment set --question` replaces it on purpose — use it to fix the wording, never to make the question match the results. An experiment whose question drifts to match its results has stopped being an experiment. The **conclusion** is the answer, once the work gives one: what was found and the evidence for it, with both sides' numbers for a comparison. Change it when later work changes the answer; `--conclusion ""` clears it. An agent cannot overwrite a conclusion a person wrote. If you cannot write a question, you want a project-direct run instead. That is a legitimate shape, not a shortcut: work with no hypothesis has an honest home, and it is better than an experiment named after your working directory. ### Freezing ```bash theme={null} probe experiment freeze dockq # mint an immutable version pinning the current run set probe version list dockq probe version create dockq # a launch-time manifest ``` This is what you cite when the numbers go into a paper or a decision — the run set is pinned and cannot drift underneath the claim. ### Reproduction ```bash theme={null} probe experiment reproduce dockq # per-run reproduction summaries probe run reproduce $RUN # the server-assembled record for one run ``` See [snapshots](/tracking/snapshots.md) for what those records contain. ## Run groups A group collects peer runs: a sweep, an ensemble, the ranks of one distributed job. ```bash theme={null} GROUP=$(probe group create dockq --name "lr sweep" --kind sweep --spec @search-space.json) probe run start --experiment dockq --group $GROUP --name lr-3e-4 probe group list dockq probe notes append --experiment dockq --text "lr sweep: seed 3 diverged; excluded from the median" ``` What the sweep tests goes in the experiment's notes, never in `--name`: the name is part of the group's identity within the experiment, so a description added to it makes a second group. ## Tags Tags are free-form labels. The same grammar works on projects, experiments, runs and papers (`probe project tag`, `probe experiment tag`, `probe run tag`, `probe paper tag`). ```bash theme={null} probe run tag $RUN baseline reproduced # add probe run tag $RUN --remove reproduced # drop probe run tag $RUN --set final # replace the whole set probe run tag $RUN # bare: list ``` Filtering by several tags is **AND**: ```bash theme={null} probe run list --tag baseline --tag grpo probe project list --tag dockq ``` ## Lineage ```bash theme={null} probe edge add --source run:abc --relation produces --target artifact: \ --reason "the eval script wrote this table" probe edge remove probe experiment edges dockq # every edge under an experiment ``` Edges connect runs, files, file versions, papers, sources, experiments and projects. They are what make "what produced this checkpoint" answerable later. `--source` and `--target` are `type:ref`; `--relation` is one of `consumes`, `produces`, `evaluates_on`, `promoted_to`, `derived_from`, `forked_from`, `resumed_from`, `retried_from`, `branched_from`, `discovered_via`, `supersedes`, `informed_by` or `relates_to`. Adding an edge that exists is not an error: it prints that edge's id. A wrong edge is fixed by removing it and adding the right one. `probe edge remove` takes the edge's id, which `probe edge add` prints and `probe experiment edges` lists as `id`. For what a run trained on or started from, record a use instead: see [datasets](/tracking/datasets.md#what-a-run-used). ## Deleting ```bash theme={null} probe project delete folding --dry-run # what would go, whose it is, when it last changed probe project delete folding probe experiment delete dockq probe run delete $RUN ``` A delete **moves** the thing and everything under it to the trash: a project takes its experiments and runs with it, an experiment its runs, a run its telemetry. Trashed work disappears from every list, search and agent read, and a link to it says it is in the trash. `--dry-run` changes nothing and prints what would move. > [!WARNING] > > **Only Probe staff can restore from the trash**, for 21 days after the delete; then it is deleted for good. To get something back, email [support@prbe.ai](mailto:support@prbe.ai). There is no restore command or button. > > A project with live subprojects refuses to delete unless you pass `--recursive`. Deleting requires a credential with the `delete` scope. Files are different: `probe artifact delete` does not use the trash and is permanent. See [artifacts](/tracking/artifacts.md#housekeeping). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.