What do the capability terms mean?

Drift is any gap that opens between two things that are supposed to match: the requirement and the spec, the spec and the code, the docs and the behavior, the model and the world it models. One record is declared authoritative, reality moves on, and the record stays behind, so the gap grows quietly, a little at a time, and nothing announces it. What is drift catalogs the forms it takes, fourteen in all, from spec drift and implementation drift to process drift and priority drift.

The structured delivery methodology behind the platform. Cascades encodes discipline in software: it has four phases, each producing an artifact the next phase consumes, and the platform enforces the structure while the human provides direction and judgment. A failure is contained at the phase where it is caught, work flows continuously, and sequencing follows the dependency graph with no sprint boundary to plan around.

Short for AI Development Lifecycle, and driftless's term for the practical operating cycle of Cascades: the five stages a piece of work travels when agents do the building. A human directs. Agents shape the work into specifications. Gates validate the spec before anything builds. Agents ship. Verification proves the result against acceptance criteria that were written before the code existed. Every stage produces an artifact the next stage consumes, and a failure caught at one stage never flows downstream. AWS uses the name AI-DLC for AI-Driven Development Lifecycle, with Inception, Construction, and Operations stages; driftless uses AIDLC for the Cascades operating cycle here, and the two are distinct methods.

The first phase of the Cascades cycle. Business conviction becomes structured, testable work: a business analyst agent translates the conviction into paired PRD sections and tech spec sections that stay traceable to each other, decomposes the work into tasks with testable acceptance criteria, and maps the dependencies between them. Sequencing is determined by what unlocks the most downstream value. The human brings the conviction and the agent brings the structure.

The second phase of the Cascades cycle. Spec gates evaluate every PRD and tech spec section pair across three checks before any code is written: integrity (is each spec buildable, are acceptance criteria testable, and is there traceability between requirements and tasks), collisions (do sections contradict each other, and does the PRD contain architecture that belongs in the tech spec), and consequences (are there dependency gaps, or requirements with no owning task). A failed gate blocks downstream execution until the spec is clean, and the findings point to the exact section and problem. Automated deterministic checks run alongside agent reasoning; no human review is required for the gate to run.

The third phase of the Cascades cycle. Persistent coding agents execute the shaped, gated work: each agent reads its task directive, writes code, runs tests, and posts progress updates to the task record. Multiple agents work in parallel on independent tasks, and dependency chains prevent an agent from starting work that is still blocked. Code, tests, and progress commentary are logged for audit, and agents persist across sessions rather than losing context between one session and the next.

The fourth phase of the Cascades cycle. The acceptance criteria written at shape time are tested against the shipped code, and each criterion has a clear pass or fail, so the criteria tested are exactly the ones written before the code existed. Automated validation runs first: CI gates, regression tests, and agent code review. A human verifies the final result and marks the task done, so tasks move to done only after that confirmation. Work that still fails after bounded retries escalates to a human blocker, and failed work is never marked done.

Driftless writes product and technical documentation as a pair: PRD sections say what and why, tech spec sections say how, and the two stay paired with bidirectional traceability. Every requirement traces to a spec, every spec traces back to a requirement, every task links to its source section, and every section lists its implementing tasks. Spec gates read the pair together, which is how contradictions between sections get caught before code is written.

The testable statements of what a task must produce, written before the code exists and locked at spec time. They are written TDD-ready in Given/When/Then form, and each one has a clear pass or fail: a criterion that cannot be tested that way, such as a statement that the system should be fast, does not pass review. Verification checks the shipped code against the same criteria written at shape time, and a passing build alone does not complete a task.

The full context a coding agent executes against when it picks up a task: the task description, its acceptance criteria, the project context, linked tasks, and comments. Agents are orchestrated against task directives, so the work was already defined and validated in the earlier phases; the agent executes the brief that the directive carries.

The map of which tasks depend on which, and the plan a cycle runs on. Sequencing follows the graph, work flows continuously, and the plan updates as work completes. Dependency chains also prevent coding agents from starting work whose dependencies have not landed yet.

The record of proof attached to shipped work: check results, test output, and verification entries that agents post to the task record as they work. The task record preserves decisions and progress, so a reviewer can follow why the work happened and how it was checked without attending a meeting.

Agents that keep their working context across sessions. A persistent agent executes independently with full context and accountability: it picks up tasks, posts updates, and ships in real time, and it does not lose the thread of its work between one session and the next.

The hosted business analyst agent. It runs the Shape and Gate phases of the Cascades methodology, framing problems, pinning decisions, and writing paired PRDs and tech specs with TDD-ready acceptance criteria. It operates the platform directly through MCP tools, loads domain skills on demand, curates its own memory across sessions, and forks a new context when it detects that a conversation has shifted topic.

The terminal control center for coding agents. It runs on the operator's machine, commits to the operator's repositories, polls the driftless task board for assigned work, and dispatches the operator's coding agent automatically. A terminal UI shows a pinned task header, live logs, a todo snapshot, and model, token, and cost telemetry. Agent tokens are minted by a browser sign-in flow and stored in the OS credential store, and driftless never holds the coding-agent credentials.

The builder agent that ships code, dispatched by the Orchestrator. It runs locally, on the operator's machine, in the working copy of the repository configured for it, and it executes build, test, and lint commands there as a local process. It cannot reach the network unless the operator allows it, and concurrent coding agents each get their own git worktree. Agents do not certify their own completion: a person decides what merges and what deploys.

Short for bring your own key. Driftless runs on the operator's model keys: the operator selects the model and the provider, and inference runs where the operator wants it. Preset providers include OpenAI, Anthropic, OpenRouter, and Ollama, and any OpenAI-compatible endpoint is supported through its base URL. Deleting a provider connection removes the key and the connection immediately, and it stops model calls through that provider only.

The per-user storage that holds provider keys. Each key is encrypted with AES-256-GCM before it is written, and the vault is scoped to the user's account within each organization. Provider settings hold only a vault reference, never the raw key, saved keys display masked everywhere in the app, and no API response returns key material. Model calls are proxied by the server: the key is read from the vault for the call and never persisted outside it.

The deliberately narrowed execution environment an agent runs inside, defining what the agent can touch and nothing more. Driftless runs agents in two sandboxed contexts: hosted agents run in the multi-tenant server, isolated from other tenants, and coding agents run on the operator's machine, isolated from the network and limited to the designated checkout. In both, agents are tool-limited and cannot self-certify completion or push to production on their own.

The record kept of the files an agent intends to touch. Before an agent is dispatched, the files it intends to change are recorded and checked against the intents of agents already working, so overlapping work is caught before dispatch and before any merge conflict could form.