# Glossary

The terms you meet across the Bumpkit docs, in alphabetical order. Each entry links to the page that covers it in full. Terms marked Beta belong to features in early access.

## A

### Agent guard

> **Beta, early access.** Flag: `agent_guard`.

`bumpkit guard` runs the release gate on a coding agent's work before the agent finishes or pushes, and sends it back with the reasons when the gate fails or needs approval. See [Agent Controls](/docs/agent-controls#agent-guard) and [Agent Hooks](/docs/agent-hooks).

### API key

The secret that authenticates the CLI, the MCP server and your own scripts. Send it in the `x-api-key` header; `Authorization: Bearer` isn't read. In CI, set it as `BUMPKIT_API_KEY`. See [API Reference](/docs/api-auth#authentication).

### Approver

A person whose approval satisfies a rule. A rule can limit approvers with `approvers` (GitHub logins or `@org/team`) or `codeowners: true`; otherwise any reviewer counts, except the author, bots and coding agents. See [Approvals](/docs/approvals).

### Area

A part of your product a change touches. A risk area is one of `authentication`, `authorization`, `billing` or `cryptography`, found by the release check. A blast radius area is any area the change reaches through the call graph, named from your policy, CODEOWNERS or the top-level directory. See [Release Checks & Blast Radius](/docs/release-checks#how-areas-are-named).

## B

### Back-port

A fix that shipped in a release tag but is missing from the branch you are releasing. The gate reports each one as a `missing_backport` finding, and [`hotfix.backports`](/docs/bumpkit-yml#hotfix-backports) decides whether it blocks, needs approval or is ignored. See [Hotfixes & Break Glass](/docs/hotfixes#back-port-detection).

### Base

The version or ref a release starts from, usually the pull request's base or the latest tag. With the Bumpkit GitHub App installed on the repository, the gate reads `bumpkit.yml` from the base itself, so a pull request can't loosen its own rules. Without the App, it uses the policy the CLI or Action sends. See [Release Gate](/docs/release-gate#the-policy-comes-from-the-base).

### Beta and early access

Most Bumpkit features are in Beta, which means early access: they are on only for workspaces that have been given access. Until yours has it, the dashboard shows an early-access page where you request it, the API answers `403 FEATURE_EARLY_ACCESS` with a link to that page, and the CLI prints the same message. A feature that isn't available at all answers `404`. Run `bumpkit features` to see what is on for your workspace. See [Troubleshooting](/docs/troubleshooting#feature-not-enabled).

### Blast radius

> **Beta, early access.** Flag: `blast_radius`.

The product areas a change reaches when you follow every caller of the changed code through the call graph, with the file and line of each call. [`blast_radius.approve_areas`](/docs/bumpkit-yml#blast-radius-approve-areas) asks for approval when a guarded area is reached. See [Release Checks & Blast Radius](/docs/release-checks#blast-radius).

### Break glass

An emergency override: a workspace owner, admin or policy admin lets one exact commit through the gate with a written reason. It is the same thing as an [override](#override). [`break_glass: false`](/docs/bumpkit-yml#break-glass) turns it off for a repository. See [Hotfixes & Break Glass](/docs/hotfixes#break-glass).

### bumpkit.yml

The policy file at the root of your repository (`.bumpkit.yml` also works). Its `gate:` section sets what blocks a release and what needs approval; a file with a mistake fails closed, never falls back to the default. See [bumpkit.yml Reference](/docs/bumpkit-yml).

## C

### Changelog page

A public, hosted page and RSS feed of your workspace's releases, at `https://bumpkit.dev/c/your-slug`. See [Changelog Pages](/docs/changelog-pages).

### Check

A release check reads the code between a base and a head, proves what changed and lists it as findings with a verdict. Run it with `bumpkit check` or `POST /v1/checks`. See [Release Checks & Blast Radius](/docs/release-checks).

### Claim

> **Beta, early access.** Flag: `swarm_claims`.

A lease an agent takes on a resource, such as a migration number, file, symbol or route, so other agents in the same repository don't use it at the same time. See [Agent Swarms](/docs/agent-swarms#claims).

### Close the loop

> **Beta, early access.** Flag: `close_the_loop`.

Bumpkit opens the rollback, back-port or caller fix as a pull request, routes it to the right person or agent, and marks it done only when a later gate run proves it. Bumpkit never merges. See [API Reference](/docs/api-releases#close-the-loop) and [Agent Swarms](/docs/agent-swarms#fix-tasks).

### Confidence score

> **Beta, early access.** Flag: `confidence_score`.

One number on each gate decision: how confident Bumpkit is that the release won't need a revert, a hotfix or an incident. It learns from what happened to your past releases. See [Confidence Score & Leadership](/docs/confidence-score).

### Contract

> **Beta, early access.** Flag: `contract_checks`.

An API definition clients depend on: an OpenAPI or Swagger spec, a GraphQL schema, a protobuf file or a JSON Schema. Contract checks compare the old and new versions and report every change that breaks a client. See [Contract Checks](/docs/contract-checks).

## D

### Decision

What the gate concludes about a change: `pass` (nothing stops it), `needs_approval` (a rule needs a person's approval first) or `fail` (a blocking finding or failed requirement). Approval can't turn a `fail` into a `pass`; only an [override](#override) can. See [Release Gate](/docs/release-gate).

### Deploy

> **Beta, early access.** Flags: `forensics` or `release_health`.

A record that a version went live in an environment, with the commits it shipped and the lines each one changed. Send it with `bumpkit deploy`, `POST /v1/deployments` or the GitHub App. Release health needs it. See [Release Health & Forensics](/docs/release-health#record-deploys).

## E

### Evidence

The word has two meanings. On a finding, `evidence` is `deterministic` (proven by the diff) or `inference` (the model's reading, which never decides the gate). In compliance, evidence is the tamper-evident export of releases, gate decisions and overrides that you give an auditor. See [Release Checks & Blast Radius](/docs/release-checks#findings) and [Compliance Evidence](/docs/compliance).

## F

### Finding

One thing a check proved or noticed, with a `kind` (such as `secret` or `breaking`), a `severity`, the file and line, and its `evidence`. See [Release Checks & Blast Radius](/docs/release-checks#findings).

### Freeze

> **Beta, early access.** Flag: `change_freezes`.

A period when releases stop, either scheduled in the policy or declared on demand. See [Org Policies & Freezes](/docs/org-policies#release-windows-and-change-freezes).

## G

### Gate

The release gate decides whether a change may ship under your `bumpkit.yml`. It runs a check, works out whether a coding agent wrote the change, counts approvals and returns a [decision](#decision). See [Release Gate](/docs/release-gate).

## H

### Head

What is being released: the end of the range a check reads, `HEAD` by default. `working-tree` includes uncommitted work. See [Release Checks & Blast Radius](/docs/release-checks#run-a-check).

### Hotfix

An urgent fix shipped from a release. The gate treats a change as a hotfix with `--hotfix` or a branch named like `hotfix/...` or `release/...`, and holds it to the [`hotfix`](/docs/bumpkit-yml#hotfix) rules. See [Hotfixes & Break Glass](/docs/hotfixes).

## I

### Inbox

> **Beta, early access.** Flag: `approval_inbox`.

One list of what waits for a person: gate approvals, paused agent commands, pending memories and lesson proposals, ranked by risk. Low-risk items can be approved in a batch with a typed confirmation. See [Agent Swarms](/docs/agent-swarms#approval-inbox).

### Incident

> **Beta, early access.** Flag: `forensics`.

A production error Bumpkit traced to the releases shipped before it, with ranked suspects. Incidents come from release health regressions, from error sources such as Sentry, or from `bumpkit incidents report`. See [Release Health & Forensics](/docs/release-health#what-broke-production).

## L

### Lesson

> **Beta, early access.** Flag: `swarm_lessons`.

A repository-wide rule, such as a practice, a pitfall or a decision, that any agent can propose and only a person can approve. Approved lessons reach every agent at the start of its session. See [Agent Swarms](/docs/agent-swarms#swarm-lessons).

### Locked key

> **Beta, early access.** Flag: `org_policies`.

A gate key listed under `locked` in the org policy. A repository's `bumpkit.yml` can make a locked key stricter but not looser. See [Org Policies & Freezes](/docs/org-policies#how-the-org-policy-and-bumpkit-yml-combine).

## M

### Memory

> **Beta, early access.** Flag: `codebase_memory`.

What agents and people learned about a repository, stored by path: decisions, pitfalls, incidents and notes. Agents recall it when they start work in an area. See [Agent Controls](/docs/agent-controls#codebase-memory).

### Merge plan

> **Beta, early access.** Flag: `merge_planning`.

An order for a repository's open pull requests, so the ones with the fewest overlaps merge first and stacked ones follow their base. Use `bumpkit merge-plan`. See [Agent Swarms](/docs/agent-swarms#merge-planning).

## O

### Org policy

> **Beta, early access.** Flag: `org_policies`.

One gate policy for the whole workspace, merged with each repository's `bumpkit.yml`. If Bumpkit can't read it, the gate fails closed. See [Org Policies & Freezes](/docs/org-policies#org-wide-policies).

### Override

A decision by a workspace owner, admin or policy admin to let one exact commit through the gate anyway, with a reason of 10 to 500 characters. It can require a post-hoc review and is kept in the audit log and compliance evidence. A person does it signed in to the dashboard, on the commit's check page. Also called [break glass](#break-glass). See [Release Gate](/docs/release-gate#overrides).

### Owner and roles

The workspace owner can do everything, including overrides, billing and deleting the workspace. Admins can do everything except billing and deleting the workspace. With the `roles` flag (Beta), members get one of seven roles, from owner to viewer and auditor. See [SSO, SCIM & Roles](/docs/sso#roles).

## P

### Pause

> **Beta, early access.** Flag: `agent_pause`.

A hook that checks each shell command or file access before an agent runs it, and allows it, asks a person or denies it with a reason. See [Agent Controls](/docs/agent-controls#pause-risky-commands).

### Policy

The rules the gate applies, written in the `gate:` section of `bumpkit.yml`. A repository without one uses the default policy. See [bumpkit.yml Reference](/docs/bumpkit-yml#default-policy).

### Predictor

> **Beta, early access.** Flag: `regression_predictor`.

`bumpkit predict` ranks the existing areas a change can break, each with a likelihood, from the areas it reaches and their incident history. See [Rollback & Time Machine](/docs/rollback#regression-predictor).

### Proven change

> **Beta, early access.** Flag: `proven_changes`.

A kind of change, in one part of a repository, that Bumpkit is 95% sure causes a problem less than 5% of the time, measured from merged pull requests. It only measures: the release gate doesn't change. See [Proven changes](/docs/confidence-score#proven-changes).

### Provenance

> **Beta, early access.** Flag: `change_provenance`.

A record, per release check, of which agent made the change: its version and model, the session, the tools it used, the human sponsor, the approvals and the verification evidence. See [Agent Controls](/docs/agent-controls#ai-change-provenance).

## R

### Regression

> **Beta, early access.** Flag: `release_health`.

A release that made production errors worse. Release health calls a deploy `regressed` when the error rate rises significantly or an error is `new` or `regressed`, and opens an incident. See [Release Health & Forensics](/docs/release-health#regression-verdicts).

### Release docs

> **Beta, early access.** Flag: `release_docs`.

Release notes Bumpkit writes from a release check: what the commits say and what it proved in the code. You can publish them and tailor them per audience. See [Release Notes & Digests](/docs/release-notes).

### Release health

> **Beta, early access.** Flag: `release_health`.

Bumpkit's verdict on a deploy, `healthy`, `degraded`, `regressed` or `unknown`, from comparing production errors after it went live with before. Run `bumpkit release health VERSION`. See [Release Health & Forensics](/docs/release-health).

### Release train

> **Beta, early access.** Flag: `release_trains`.

A named group of pull requests that ship together as one version. Each pull request merges on its own; cutting the train creates one version, changelog entry, tag and GitHub Release. See [Release Trains](/docs/release-trains).

### Multi-repo train

> **Beta, early access.** Flag: `multi_repo_trains`.

One release across repositories, in dependency order. Each repository's step has its own gate result, and a step that isn't released holds every later step. See [Release across repositories](/docs/release-trains#release-across-repositories).

### Rollback plan

> **Beta, early access.** Flag: `intelligent_rollback`.

The smallest set of commits to revert to undo a regression, with the later commits that depend on them, proven to apply in a temporary worktree. A workspace owner or admin opens it as a pull request. See [Rollback & Time Machine](/docs/rollback#intelligent-rollback).

## S

### Scorecard

> **Beta, early access.** Flag: `agent_scorecards`.

A per-agent summary of how its releases fared: shipped clean, blocked or needed approval, and what it was flagged for most. Use `bumpkit scorecards`. See [Agent Controls](/docs/agent-controls#agent-scorecards).

### Suspect commit

> **Beta, early access.** Flag: `release_health`.

A commit Bumpkit ranks as a cause of a production error, with a likelihood, because its changed lines, functions or files match the error's stack frames. See [Release Health & Forensics](/docs/release-health#suspect-commits).

## T

### Tamper-evident

How compliance exports prove nothing was changed, removed or reordered: `bumpkit evidence verify` catches any edit. See [Compliance Evidence](/docs/compliance#tamper-evident).

### Time machine

> **Beta, early access.** Flag: `release_time_machine`.

`bumpkit when` finds the first release where a symbol, file, dependency between areas or kind of finding appeared, and the commit that introduced it. See [Rollback & Time Machine](/docs/rollback#release-time-machine).

## V

### Verdict

A release check's own opinion: `block`, `review` or `ship`. It is separate from the gate's [decision](#decision), which is what decides whether a change may merge. See [Release Checks & Blast Radius](/docs/release-checks#verdicts).

## W

### Window

> **Beta, early access.** Flag: `change_freezes`.

A release window is a time when releases are allowed, set with `windows` in the policy. Outside it, `outside_windows` decides what the gate does. See [Org Policies & Freezes](/docs/org-policies#release-windows).

### Workspace

Your team's account in Bumpkit. API keys, checks, gate decisions, incidents, settings and members all belong to one workspace, and its per-minute rate limit is shared by all its keys. See [Getting Started](/docs/).