Glossary
Where a term has a specific meaning in Valved different from its general meaning, the Valved definition takes precedence.
Agent — A declarative role the AI harness runs: a markdown file with YAML frontmatter (name, description, model, tools, allowed_paths, max_mode, classifications) plus a system-prompt body. A user file at valved/agents/<name>.md overrides a built-in of the same name.
Agent loop — The pattern where an agent receives a goal, calls tools, reads results, and continues until it produces an answer or hits a limit. The harness adds permission gating, context management, and subagent delegation on top.
Ask — A read-only investigative query, answered by the explorer subagent in read_only mode. Produces a cited answer and changes nothing. Invoked via valved ask.
Backend — In Valved, “backend” means dlt or dbt (the external tools Valved drives) — not a database or server-side app.
Brownfield — Adopting Valved into an existing dbt/dlt project. Valved infers conventions and references existing components without rewriting them. A central adoption mode, not a corner case.
Build — The verb that materializes a reviewed Plan into files (dlt code, dbt models, pipelines/<name>.toml). Writes files; does not deploy.
Component — An independently-versioned dlt or dbt unit the control plane references by name, rather than containing. Discovered by convention (simple mode) or declared as [components.<name>] (multi mode).
Control plane — Valved’s core identity: it builds, schedules, and monitors pipelines by referencing independently-versioned dlt/dbt/sql components. valved.toml is the control-plane config.
Conventions — A project’s inferred house style (naming, layout, tagging, test patterns), loaded into agent context so generated code matches existing code. Refreshable via valved memory refresh.
DAG — The step graph of a pipeline: dlt, dbt, and sql steps with explicit depends_on edges, run in parallel where the graph allows.
Deploy — Promotion of built code from dev to prod via a handoff (files → commit → push → pr, default pr), with linked PRs across repos. Valved opens the PRs; you merge.
Deploy handoff — The configurable stopping point of a deploy: files, commit, push, or pr.
dlt — The extract-load tool Valved drives for ingestion. A dlt source yields dlt resources; the DLT engineer authors both.
Graduation — Moving a component from co-located (same-repo) to its own path or repo, pinned by ref — one guided command, no pipeline rewrites.
Greenfield — Starting a new project with Valved from scratch. Contrast with brownfield.
Harness (AI harness) — Valved’s Claude-Code-style agentic engine: the orchestrator loop, subagent delegation, terminal-grade tools, permission modes, and the verify-by-execution loop.
Hook — A user-defined action fired at a lifecycle point (e.g. post_build), configured in valved/hooks.toml.
Investigation — A durable failure record produced by the recovery engineer when retries are exhausted: a diagnosis plus a proposed Plan that flows through the normal build/deploy path.
Job — A unit of work claimed from the Postgres queue by a worker (optimistic FOR UPDATE SKIP LOCKED).
MCP — Model Context Protocol. Valved both exposes an MCP server (valved mcp-serve) and consumes external MCP servers (valved mcp-servers).
Memory (project) — Conventions (inferred), standards (authored), and the decision log — managed via valved memory.
Multi mode — Components declared as [components.<name>] blocks pointing at separate paths/repos. Contrast with simple mode.
Orchestrator — The harness’s main loop: classifies intent, decomposes goals, and delegates to domain subagents.
Permission mode — The harness’s authority level for a task: read_only, plan, build, or deploy. Grants are tighten-only.
Pin — An exact component version (commit SHA or tag) checked out for a run. Precedence: ref → branch → default-branch HEAD.
Pipeline — A named DAG of dlt/dbt/sql steps referencing components by name, defined in pipelines/<name>.toml.
Plan — A reviewable, durable artifact produced from intent: file diffs plus a cost estimate. Iterable via plan --refine.
Reaper — The supervisor loop that reclaims jobs from crashed workers after a missed-heartbeat threshold.
Recovery engineer — The subagent that diagnoses failed runs (grounded in real dlt/dbt exceptions) and proposes reviewable fixes — never writing to prod autonomously.
Refine — Iterating on a draft plan (valved plan --refine <plan_id>); the new plan records parent_plan_id.
Run — A single execution of a pipeline against a target, on demand or scheduled.
Runtime — The control plane’s execution machinery: scheduler, reaper, archiver, and worker pool over a Postgres queue.
Seed schedule — A pipeline’s optional [seed_schedule] block, applied only at first registration. Thereafter the live schedule is data, changed via valved schedule.
Simple mode — The default: control-plane config and all components co-located in one repo, components discovered by convention. Contrast with multi mode.
Skill — A packaged capability (SKILL.md) an agent can invoke; distributed in skill packs.
Target — A named environment a run executes against (dev, prod), defined in valved/connections.toml, carrying a dialect and role-scoped credentials.
The full glossary lives in the project’s specs/reference/glossary.md.