Glossary
A plain-English reference for common Bilbis terms.
A
Active session
A browser, device, or CLI client currently signed in to your Bilbis account. Review sessions in Security settings.
Agent
An AI role that handles one part of a pipeline. Examples include Work Planner, Repo Router, Implementation Agent, Test Runner, Review Agent, and PR Publisher. See Meet the agents. Older identifiers (Tech Lead, Senior Engineer, Code Reviewer, …) and legacy Greek codenames map to the same agents - see Agents runtime names.
Approval
A human confirmation that lets a pipeline merge its MR/PR. Pipelines can pause in Awaiting approval until approval arrives. See Clarifications and approvals.
Awaiting clarification
A waiting state where an agent has asked a question before continuing. Answer from the pipeline detail page, or from Jira when Jira is configured. See Awaiting clarification.
B
Branch prefix
The prefix Bilbis adds to branches it creates, such as feat/. Configure it on a product. See Products.
Bring your own key
The model where your organization supplies provider keys or tokens. Also called BYOK. See BYOK.
Budget alert
An email notification when current-month pipeline spend crosses a threshold. See Analytics.
Budget cap
The maximum amount one pipeline can spend in US dollars. If the cap is reached, the pipeline fails instead of continuing to spend. See Budgets, dry runs, and priority.
C
Cancel statuses
A list of Jira status names that cancel any in-flight pipeline for a ticket if the ticket moves into them. Configured on the org-wide Jira card or on a per-product override. Empty disables auto-cancel. See Jira setup.
CI
Continuous integration checks run by your Git provider or CI system. A pipeline can enter CI while waiting for checks or CI fixing while trying to repair failures.
Clarification
A question from an agent. Clarifications are safer than guessing when the task, repo, branch, or desired approach is unclear.
Credential
A saved provider key or token. Credentials let Bilbis use providers such as Anthropic, OpenAI, GitLab, GitHub, Jira, SendGrid, or Cloudflare. See Integrations settings.
D
Dashboard
The organization overview showing setup status, active work, recent pipelines, cost movement, throughput, and top engines. See Dashboard.
DEK
Data-encryption key. A per-tenant key used to encrypt that organization's secrets at rest. Each DEK is wrapped (encrypted) by a master-key version. Key rotation re-wraps DEKs under a newer master key without re-encrypting any tenant data. See Platform Admin → Encryption.
Dry run
A pipeline mode that runs planning and coding, then stops before pushing a branch or opening an MR/PR. Dry runs still spend money because the agents still work. See Budgets, dry runs, and priority.
E
Engine
The AI model or model family Bilbis uses for agent work. Users can pick an engine or let Bilbis choose automatically. See Task types and engines.
F
Fingerprint
A 16-character SHA-256 prefix that identifies a master-key version without exposing the key itself. Operators compare fingerprints across environments and against what's stored in 1Password to confirm a master-key rollout. See Platform Admin → Encryption.
G
Git provider
The service where your repositories live. Bilbis currently documents GitLab and GitHub provider setup. See Git providers.
Group
An organization access group that connects members to products. Groups help control who can see and work with product areas. See Groups.
H
Hold statuses
A list of Jira status names that pause a pipeline. The pipeline transitions to Paused — ticket on hold and resumes automatically once the ticket leaves all hold statuses. Configured on the org-wide Jira card or on a per-product override. Empty disables auto-pause. See Jira setup.
I
Integration
An external service Bilbis uses, such as an LLM provider, Git provider, Jira, SendGrid, or Cloudflare. See Integrations overview.
J
Jira
A ticketing integration. Bilbis can use Jira for ticket-triggered pipelines, clarification replies, and MR/PR links when configured. See Jira setup.
L
Language profile
Per-repository language breakdown by percent (for example { TypeScript: 66.4, Vue: 30.5 }). Bilbis fetches it from the Git provider's languages API using the org's BYOK token and renders it as a GitHub-style stacked bar on the repository row. Older than 30 days surfaces a Stale badge. Admins can refresh on demand. See Repositories → Languages.
Learning
Planned repository-specific knowledge that agents will reuse in later pipelines. Learnings is currently marked Shipping soon in the app. See Learnings.
LLM provider
The AI provider used by the agents, such as Anthropic or OpenAI. See LLM providers.
M
Master key
Server-side encryption key (MASTER_KEY_V* Wrangler secret) that wraps the per-tenant DEKs. Multiple versions can be configured at once - the highest version is the current one new DEKs wrap under, while older versions stay loaded so existing wrapped DEKs can still be unwrapped. Identified by a 16-character fingerprint. See Platform Admin → Encryption.
Merge blocked
A red banner that sits under the Awaiting approval banner when the provider rejected Bilbis's last merge attempt. Names the reason in plain English (CI must pass, conflicts, draft state, branch protection, missing approvals, open discussions) and links to the MR/PR. A scheduled job retries every ten minutes. See Clarifications and approvals → Merge blocked.
Merge request
The GitLab review object Bilbis opens after pushing a branch. Often shortened to MR.
MR/PR
A shorthand for merge request or pull request when a statement applies to both GitLab and GitHub.
MFA
Multi-factor authentication. Bilbis currently documents TOTP-based two-factor authentication with recovery codes. See Multi-factor authentication.
O
Organization
The organization where a team uses Bilbis. It contains members, credentials, products, repositories, pipelines, billing, analytics, and audit history. See Organizations and roles.
P
Pipeline
One Bilbis run. You describe a task, and Bilbis moves it through planning, coding, testing, review, and merge. See What is a pipeline.
Planning
An active pipeline state. The Work Planner decomposes the task into file-level steps before the Implementation Agent starts coding. Skipped on short single-repo tasks. See Pipeline lifecycle.
Product
A group of related repositories that share automation settings such as branch prefix, MR/PR labels, preferred engine, review wait, approval timeout, and auto-merge behavior. See Products.
Pull request
The GitHub review object Bilbis opens after pushing a branch. Often shortened to PR.
Q
Quality score
A 0-100 directional signal from agent self-assessment and reviewer feedback. It helps spot trends but does not replace human code review. See Analytics.
R
Recovery code
A one-use code that can be used when you cannot access your authenticator app. Save recovery codes when enabling MFA.
Repository
The codebase Bilbis can work in. A repository belongs to a product and points to a GitLab or GitHub project. See Repositories.
Role
The permission level a user has inside an organization. Common roles are Owner, Admin, Developer, and Viewer. See Organizations and roles.
T
Template
A saved New Pipeline form preset. Templates help repeat common pipeline tasks without filling every field again. See Templates.
TOTP
Time-based one-time password. This is the 6-digit code generated by authenticator apps for Bilbis MFA.
Transition field mappings
A per-status map of Jira field IDs to values. Bilbis sends these values when it moves a ticket through a workflow status that requires fields (for example customfield_<sprint_start> and customfield_<due_date> on Code Review). Without the mapping, Jira refuses the transition and the pipeline pauses at Configure Jira fields. Supports placeholders like {{today}}, {{today+Nd}}, {{now}}. See Jira setup → Transition field mappings.
Triggered by
The actor that started a pipeline, shown in the By column of the pipelines list. Conventions: Jira: <displayName> for Jira-webhook runs, GitLab: <name> for GitLab-webhook runs, <email> for runs dispatched from the New Pipeline form, and Container (parent <id8>) for orchestrator child-spawns. Falls back to the Bilbis seat email when no actor label is set.
W
Webhook
A provider callback that lets GitLab, GitHub, or Jira notify Bilbis about events. See Webhooks.