Glossary

The terms used in the web app and in these pages, in alphabetical order. Labels in bold are the exact words you see in the web app.

A

Acceptance criteria check. A check of a pull request against the acceptance criteria of the issue it links. Criteria come from a section such as "Acceptance criteria" or "Definition of done", a checklist or Given/When/Then scenarios, or are inferred when the issue has none. Each criterion is Met, Unmet or Unclear. See Checks and acceptance criteria.

Admin team. A GitHub team (org/team-slug) whose members become organisation administrators in addition to the owners of the GitHub organisation. Set under Settings › Administrators.

Approval. A mode in which outputs wait in Approvals until someone posts or rejects them. Also the act of posting such an output. Pending outputs expire after seven days. See Approvals.

Assignment. Reviewer suggestions for pull requests and assignee suggestions for issues. Modes Off, Shadow, Suggest and Apply. The mode you set is the requested mode; the effective mode can be lower because of the legal sign-off, works-council mode or a missing opt-in. See Reviewer suggestions.

Audit log. The tamper-evident record of every change made through the web app or the API, per organisation and for the instance.

B

Break-glass. Emergency access for the operator of a self-hosted instance when no instance administrator can sign in. quavon break-glass prints a one-time link valid for 15 minutes; the session is limited to instance administration and shows as Emergency access. See Operations.

Budget. A spending limit per period for model calls, for the organisation or a repository. When it is reached, CodeLotse either uses a cheaper tier or stops model calls. Budget alerts appear at the thresholds you choose.

C

Calibration. How often comments of each category were acted on, by confidence. CodeLotse uses it to rank findings once enough samples exist.

Check run. The status CodeLotse reports on the head commit of a pull request, named CodeLotse. On GitHub it is a check run with annotations; other code hosts get a commit status or a Code Insights report. It fails only when Fail the check on critical findings is on and a critical finding is open.

Code host. The platform that hosts your repositories: GitHub, GitHub Enterprise Server, GitLab, Azure DevOps, Bitbucket Cloud, Bitbucket Data Center, Gitea or Forgejo.

Code index. A searchable index of the default branch of a repository, so reviews can find similar code and every place that uses a changed definition. Modes Off, Lexical (full-text search) and Hybrid (adds semantic search with embeddings). See Code index.

Connection. How an organisation adds a code host other than GitHub: an access token or application for GitLab, Azure DevOps, Bitbucket, Gitea or Forgejo, with its own webhook. Managed under Settings › Code hosts.

D

Deterministic checks. Scanners that run in the sandbox next to the AI review: ast-grep, Gitleaks, Bandit, gosec, Ruff and ESLint with security rules. Their findings carry a "deterministic" badge. Also called SAST.

Dry run. A review of recently merged pull requests in shadow, with the findings shown next to the comments your reviewers left. Nothing is posted. See Dry runs.

E

Effective mode. See Assignment.

Evaluation run. A recorded run of the evaluation suite that checks the quality of prompts and agents against datasets, with pass or fail gates. Visible to instance administrators under Evaluation runs.

F

Finder and verifier. The two model passes of a review. The finder proposes candidate findings from the diff and its context; the verifier checks each candidate and confirms, downgrades or rejects it.

Finding. One problem a review reports, with a file and lines, a severity, a category, a confidence, a rationale and optionally a suggested change. Its status is Candidate, Confirmed, Rejected, Downgraded, Duplicate, Below threshold, Published, Awaiting approval or Suppressed. Open findings are those not rejected, duplicated, filtered out or suppressed.

Fix run. One attempt of the fix agent to resolve an issue, or the findings of a review, in the sandbox. It ends as a draft pull request, a commit, a result in shadow, or a reason why no fix was attempted. See Issue to pull request.

Fixer app. A second GitHub App with write access to code, used only for fix runs. It is installed only on repositories that use draft fixes.

I

Inbox. The list of open pull requests across your repositories, with the ones that need you first. See Inbox and overview.

Installation. A GitHub App installed on an organisation or a personal account, with access to all or selected repositories. Each installation belongs to one CodeLotse organisation.

Instance. One CodeLotse deployment: the stack started by Docker Compose or Helm, or the cloud service.

Instance administrator. A person who manages the instance: GitHub Apps, identity providers, instance settings, telemetry, the legal sign-off and evaluation runs. The first sign-in through the setup link becomes instance administrator; more can be added with quavon grant-instance-admin. See Instance administration.

L

Learning. A statement of accepted team practice, for example "Raw SQL is fine in migrations". Reviews leave out findings that a learning explicitly allows, but never high or critical security findings. Learnings are proposed by the learn command or from replies and become active when a maintainer activates them.

Learning from feedback. The feature that reads reactions to CodeLotse's comments, calibrates confidence and proposes suppressions. Modes Off, Shadow and On.

Legal sign-off. The record of counsel's classification of reviewer suggestions under the EU AI Act for the instance. Without it, assignment runs in shadow at most.

Light code. The two lights that show the state of a review or pull request:

Light	Plain	Nautical
White, aligned	No issues	On course
Amber, slight offset	Worth a look	Drifting
Red, wide offset	Changes needed	Off course
White over red	Reviewing	Aboard
Hollow	Inactive	In port

Plain wording is the default. Each person can switch under Terminology in the account menu, and administrators set the organisation default.

M

MCP. The Model Context Protocol. CodeLotse is an MCP server that coding agents can read from with a personal access token (MCP server), and it can call MCP servers of your organisation for review context (MCP context).

Mode. How a feature behaves in a repository. For most features: Off, Shadow, Approval or Automatic. See How it works.

Model routing. Which credential and model serve each tier: Fast tier, Standard tier, Strong tier and Embeddings (optional). Set for the organisation and optionally overridden per repository.

O

Organisation. The unit everything in CodeLotse belongs to: installations, connections, repositories, members, model keys, rules and settings. Internally and in the API it is called a tenant. Data of different organisations is isolated in the database.

Organisation default. The repository settings an administrator sets once under Repository defaults. Every section of a repository's policy either follows it or is Customised.

Outbox. The table through which every event becomes a job and every approved output becomes a publication. It guarantees that nothing is lost and nothing is posted twice.

P

Pattern repository. A repository whose code every review in the organisation may compare against, for example a reference implementation. At most three per organisation.

Policy. The settings of a repository: the review mode, what is reported, how results are posted, and the mode and settings of every other feature.

Publish intent. The record of one output that is about to be posted to the code host. The publisher processes each intent once.

R

Review run. One review of one commit of a pull request. Its status is Running, Completed, Nothing to report, Failed or Skipped, and its outcome Published, Awaiting approval, Shadow only or Silent.

Role. What a person may do. Organisation roles: Administrator and Member. Repository roles: Maintainer, Reviewer and Reader. See Members and roles.

Rule. An expectation that reviews check, for example "Database access goes through the repository layer". Rules come from the web app, from .quavon/config.yml and from rule files such as AGENTS.md. Findings that break a rule have the category Rule.

S

Sandbox. The separate runner that executes repository code, scanners, tests and linters in gVisor or Firecracker, with no network by default and no access to secrets. See Sandbox.

Severity. How serious a finding is: Critical, High, Medium, Low or Nit. Critical and high count as blocking.

Shadow. A mode in which a feature runs and stores its result in CodeLotse without posting anything to the code host.

Sign-in group. A group from an OpenID Connect identity provider that an organisation administrator maps to a role. People who sign in with a company account get roles only through these groups.

Suppression. A rule that holds back a group of findings or labels people dismissed most of the time. CodeLotse proposes it; a maintainer activates it; it expires. Security and critical findings are never suppressed.

T

Tenant. See Organisation.

Tier. A class of model work. The strong tier finds and verifies findings, the standard tier writes summaries and most other outputs, the fast tier handles quick classifications, and the embeddings tier compares texts and powers semantic search.

Transparency page. The page every member can open under Assignment › Transparency. It lists what reviewer suggestions use and never use, and the mode per repository.

Triage run. One triage of a new or edited issue: labels, priority, possible duplicates and missing information.

W

Works-council mode. A protective mode for organisations with employees in Germany. While it is on, reviewer suggestions stay off until a works agreement is recorded, metrics are team-level only and the shortest retention applies.