Platform structure
Project — the tenant boundary. Capabilities, traces, datasets, runs, models, connectors, and project keys belong to exactly one project. See Administration. Guest workspace — a project minted for a guest session (POST /api/auth/guest/): read-only beyond claiming, deleted after 7 days unless claimed. Creating an account from inside it moves the project to the new account.
Agent — your product: one per project, mapped as a graph of capabilities. It has no record of its own; its identity is the project. See Agent & Capabilities.
Capability — one purpose the agent serves, and Overmind’s record of it: code structure from local sync joined with runtime behaviour from telemetry. A capability the snapshot no longer includes becomes a leftover and returns when the code does; a hand delete hides it and keeps its data. See Agent & Capabilities.
Capability card — the structured description /overmind setup writes for a capability: task, input schema, output fields, tool spec, anchors, modes, and the trajectory map. Synced in overmind.toml.
overmind.toml — the repository’s snapshot of its capabilities and their ids, kept in the repo and synced both ways with overmind sync. .overmind/credentials.toml beside it holds the project key and stays ignored.
API key — an ovr_... credential (stored hashed, shown once at creation) that authenticates the SDK, OTLP ingest, the REST API, MCP, the CLI, and inference. Sent as X-Api-Key or Authorization: Bearer. Project-scoped keys see one project; account-scoped keys reach every project the user is in.
MCP — the project-scoped Model Context Protocol server at /api/mcp/: the agent surface a coding agent uses for every workflow that does not need the filesystem. See MCP.
Skill — the overmind agent skill overmind init installs, with the /overmind commands and one reference per workflow. See CLI.
Observability
Trace — one end-to-end run of an agent: the set of spans sharing atrace_id. There is no separate trace record; the root span (the one with no parent) represents the trace in lists.
Span — one operation inside a trace, stored with its full OTLP payload (timing, status, attributes, events) plus platform fields computed at ingest. Spans are typed: entry_point, workflow, tool_call, function, retrieval, or llm_call.
Session — traces grouped by a shared conversation.id attribute, representing one multi-turn exchange. Set via set_conversation_id() or run(conversation_id=...) in the SDK. Carries a session score folded from the conversation ledger. See Trace scoring.
Trace status — live while spans are arriving or the root is missing, completed once the root has landed, interrupted when no root arrives inside the settle window.
OTLP — the OpenTelemetry wire protocol. Overmind ingests OTLP/HTTP protobuf at POST /api/v1/traces; JSON and gRPC are not accepted. See Observability.
Connector — a pull-based import from another tracing platform: Langfuse, LangSmith, Braintrust, or Galileo. Keys are added with overmind connector add or in the Console; the source project, capability mapping, and sync are MCP tools. Each runs a resumable historical backfill, then polls incrementally. See Observability.
Task — one behaviour a capability performs, minted by capability sync from its trajectory map: an entry anchor, the anchor segments after it, its tool set, and its terminal. API resource: behaviours. See Trace scoring.
Unit — the slice of a trace that gets its own verdicts: a turn span, an entry-point invocation, a key segment, or the whole trace, in that order of precedence.
Task execution — one unit bound to a task, with its verdicts, execution score, route flags, and session score. The default row of Observability.
Instrumentation plan — the exact placement tickets (file, line, decorator, scope) the get_instrumentation_plan MCP tool returns for a capability or task; verify_instrumentation grades a fresh trace against them.
Data
Dataset — a source table (a file, pasted rows, or traces, landed as-is) and a linear chain of Python cells; every cell that ran is a version. It carries an intent (train, eval, or pending until decided) and a capability, both proposed at landing and frozen by the first use. See Datasets.
Version — one cell that ran: its frame, column manifest, both contract reports and fingerprint. The source is 1.0, each cell adds a minor (1.1, 1.2), a use starts a new major (2.0) and freezes the version with every cell before it. Runs use the version they read.
Train + eval split — one source landed as two datasets with disjoint rows, <name> train and <name> eval, cut by an eval share and a position (head, tail, random). From the New dataset dialog, overmind dataset upload --split, or POST /api/datasets/split/.
Data Workshop — the dataset page: the source, Python cells with a value-level diff against the cell before, the active version with its actions, and the dataset’s own agent beside it, which shapes the chain in one preparation turn and then on request.
Contract — measured on every version, two-fold. The intent contract is the shape the intent asks for: train needs chat transcripts with an assistant turn on every row; eval needs an input on every row and reference outputs. The capability contract is row by row: an eval input carries the capability’s required keys, a train transcript is the capability’s own system prompt and tools.
Evaluation
Evaluator — one versioned scorer. Kinds:llm_judge, deterministic, trajectory, statistical, agentic. See Eval.
Claim — what an evaluator asserts: a type (grounding, verification, quality, conformance, progress, safety) and a grain (unit, trajectory, terminal, session). The claim decides how the verdict composes into the execution score. See Eval.
Rubric / checklist — an LLM judge’s plain-language criteria, compiled into weighted atomic checklist items; items can be hard gates.
Eval set — a named group of a capability’s evaluators. Members have a role: generative (score eval-run outputs) or trace scoring (score live traces, per task execution). One set per capability is active.
Eval run — a controlled experiment: one data source × N variants × M evaluators, with evaluator snapshots frozen at creation. See Eval.
Variant — one column of an eval run: either generate (re-run a model over the rows) or existing (grade traces as-is). One variant is the baseline.
Sample — one row’s normalised transcript inside a run; can be marked degraded if it couldn’t be faithfully reconstructed, excluding it from aggregates.
Score — one evaluator’s result on one sample, with a typed outcome: scored, abstained, not_applicable, skipped, or error. Only scored results feed averages.
Verdict — one evaluator’s result on one trace unit, stored as its own row — the source of truth the Console reads over GET /api/verdicts/. The unit span’s feedback_score.trace_scoring block keeps only the composed markers.
Execution score — the composite of a unit’s verdicts (0–1): safety claims cap it, gates flip their own verdict, the rest are weighted over three phases. Shown as the Score column.
Trace scoring — carving each trace into units, binding them to tasks, and judging them with the eval set’s trace-scoring members. See Trace scoring.
Runtime expectation — evidence the SDK declares during a run (intent, expect, checkpoint, eval_context) and the platform evaluates server-side.
Annotation — a human label on a sample, written through the annotate_evaluation_sample MCP tool, used as ground truth for calibrating judges.
Optimisation
Optimisation run — an experiment that edits an agent’s code: candidate diffs are generated and replayed in your checkout by the CLI, scored on the platform with a pinned eval set, and the winning diff stays on the candidate for you to apply. Modes: optimize (harness), model_comparison (backtest), hybrid. See Optimisers. Iteration — one loop cycle producing a batch of candidates. Iteration 0 is the baseline — the unmodified capability. Candidate — one proposed code diff (or, in a model comparison, one model), scored by its own eval run against the best score so far. Executioner — the local side of the loop:overmind optimise in your repository, which renders the command template, runs datapoints, applies candidate diffs, and posts outputs for scoring.
Patience — how many consecutive non-improving iterations a run tolerates before stopping early (3).
Models
Training run — one or more parallel experiments over a training dataset, each producing a candidate model (API resource:finetuning-jobs). See Training.
Baseline (training) — the capability’s production model, scored on the eval dataset at submit time; the reference every trained model’s delta is measured against.
Deployed model — a served trained model with a copyable reference (ft-...) callable via the OpenAI-compatible API. Statuses: queued, deploying, warming, ready, failed, deleting, deleted. See Inference.
Capability alias — overmind/<capability-uuid>, a model id that resolves to whichever deployment the capability has made live, so a switch never touches the calling code.
Model swap prompt — text returned by GET /api/finetuning-jobs/{id}/model-swap-prompt/ (or the get_model_swap_prompt MCP tool) after a benchmark win; paste into a coding agent to retarget the capability in your repo.
Credits — the billing unit for compute Overmind performs (judge calls, the workshop agent, training, serving), metered per user across projects. Trace ingest is never credit-gated.