# Glossary

> The product’s terms in one list.

Terms marked *(development)* apply only to development projects; they do not occur in a space without code.

| Term | Meaning |
| --- | --- |
| **AI agent** | The model that does the work in Buff: answers questions, writes the research document, runs a development task. In the documentation the same thing is also called “the model”. It reads documents and code, and writes only the answer, the research document and knowledge base entries. |
| **Token** | A piece of text — part of a word — through which the model reads and writes. Everything read counts as “input”, everything written as “output”; these are what you pay for. See [What a question costs](/en/docs/cost-of-a-question). |
| **Addressing the bot (`@buff`)** | A comment in Notion, a Google Doc, Confluence, Figma or a tracker ticket that mentions the bot or uses the `/ask` or `/research` command: a question or a research request where you work; the answer arrives in the same place. See [Ask right in your tools](/en/docs/ask-from-your-tools). |
| **Attachment** | A file attached to a question, a task draft, a clarification or a finding: Word, Excel, PowerPoint, PDF, text — up to 10 MB; read by its content. Scans without a text layer cannot be read. |
| **Observer** | A member who only watches: a Contributor with the permissions to create tasks, ask questions, start research and add findings switched off. Starts nothing and spends no balance. See [Team scenarios](/en/docs/teams/recipes#observer-view-only). |
| **Organisation** | A team’s isolated space: the owner and the members. |
| **Owner** | A member with full rights in the organisation: membership, permissions, billing, connectors. |
| **Member role** | A default set of permissions: Contributor (own tasks) or Maintainer (other people’s too). See [Members and permissions](/en/docs/teams). |
| **Permission scope** | Where a member’s role applies: the whole organisation, a development project (or a space) or a repository. The narrowest scope takes precedence. |
| **Permission** | An atomic permission for one action (“approve the formulation of other people’s tasks”); a role is a set of them that can be adjusted one by one. |
| **Audit log** | An immutable record of actions in the organisation: who, when, from where, what and with what result. Not to be confused with a project audit. See [Audit log](/en/docs/audit-log). |
| **Knowledge base** | The organisation’s shared knowledge store for people and the model: rules, facts and pitfalls. It reaches the model at every stage of work. See [Knowledge base](/en/docs/knowledge). |
| **Knowledge entry** | One entry of the base: title, one-line description, type, scope, body. One fact — one entry. |
| **Knowledge index** | The list of all entries in a scope (title + one-line description) that goes into every model run; bodies are opened on demand. |
| **“Show to the model upfront”** | An entry flag: the model receives the entry in full in every task instead of opening it when needed. Increases the spend of every task. |
| **Permanent entry** | An entry flag: the AI cannot change it or archive it; a person with change permission can. |
| **Knowledge archive** | Where an entry goes instead of being deleted: visible with read permission, restored with change permission. There is no deletion in the knowledge base. |
| **Extraction pass** | A run after finished work: reads it and writes the lessons into the knowledge base. |
| **Consolidation pass** | A run right after extraction: merges duplicates, brings descriptions up to date, archives its own outdated entries, marks discrepancies in people’s entries. |
| **“Needs review”** | A mark the model puts on a person’s entry that has diverged from the current code: it does not change such an entry itself. Cleared with the “Reviewed” button or by editing the entry. |
| **Single sign-on (SSO)** | Signing in through a corporate identity provider (IdP) via OIDC or SAML 2.0 instead of a password and an email code; the account is created on first sign-in. See [Single sign-on](/en/docs/sso). |
| **Identity provider (IdP)** | The company system that confirms an employee’s identity: Keycloak, AD FS, Entra ID, Avanpost and others. |
| **Development project** | A project where development takes place; it brings repositories together as sources. |
| **Space** | A workplace without code: questions, research and a knowledge base over the team’s documents. A permission and entry scope just like a project. See [A space without code](/en/docs/quickstart/space). |
| **Repository** | An imported mirror of an external git repository (upstream). |
| **Source** | A repository and branch (`repo@branch`) attached to a project. |
| **Upstream** | The external original of a repository (GitHub / GitLab / Bitbucket / Gitea and Forgejo). |
| **Connector** | An agent in your network: connects self-hosted git behind a firewall (or spares you handing us tokens) and runs integrations with trackers, knowledge sources and custom MCP servers on your side. See [Connector](/en/docs/connector). |
| **Integration (plugin)** | Code from the catalogue that the connector runs on its side: the link to a tracker or another of your systems. See [Catalogue](/en/docs/connector/marketplace). |
| **Connection** | An integration’s link to a specific system: address, credentials, visibility scope, development project or space. Two Jiras — two connections of one integration. |
| **Slug** | A connection’s short name. It goes into the names of the tools the model sees. |
| **Integration catalogue** | A signed list of what can be installed, with the access boundaries of every version. |
| **Visibility scope** | The repositories, projects, spaces or folders where a connection reads documents and requests and writes answers. For trackers an empty list means “nowhere”; for Notion, Confluence, Google Drive, Figma and files — everything available to the account (see [Knowledge sources](/en/docs/connector/knowledge)). |
| **Knowledge source** | An integration that lets the model read what the team has written and drawn (Confluence, Notion, Google Drive, Figma, files on disk and network shares, optionally the internet), rather than tracking tasks. See [Knowledge sources](/en/docs/connector/knowledge). |
| **Tool** | An action an integration gives the model (find tasks, read a ticket, get a diff). Writing tools are not given to the model. |
| **Event receiver** | A connector port for webhooks from external systems — trackers, Confluence, Figma. Usually optional — polling works without it. Required for GitLab commit comments and for Figma without a list of files and projects; for Figma it must be reachable from the internet. |
| **Custom MCP server** | An MCP server you added to the connector yourself — from an archive, a GitHub repository or by address; only the tools the administrator marked as read-only are given to the model. See [Custom MCP servers](/en/docs/connector/custom-mcp). |
| **Task** | A unit of work: statement → formulation → decomposition → development → review. |
| **Draft** | A task you are still editing and have not sent for refinement. |
| **Statement** | The author’s original wording of the task. |
| **Refinement / formulation** *(development)* | The stage where the analyst turns the statement into an agreed specification. |
| **Analyst** | A role of the AI agent, not an employee: in formulating a task it turns the statement into a specification and asks clarifications; in deep research it writes the document that a second agent checks. |
| **Clarifications** *(development)* | The analyst’s clarifying questions to the task’s author. |
| **Decomposition** *(development)* | Splitting a task into atoms. |
| **Atom (subtask)** *(development)* | The smallest independently buildable unit of work. |
| **Wave** *(development)* | A group of atoms executed in parallel, in dependency order. |
| **Execution scheme** *(development)* | The graph of a task’s atoms and waves. |
| **Run** *(development)* | One launch of a task’s pipeline; it can be stopped and resumed. |
| **Review** *(development)* | A person’s check of the changes before publishing. |
| **Finding** *(development)* | A review comment (from the model or a user) with a status. |
| **Publishing** *(development)* | Opening a pull request / merge request upstream after approval. |
| **Audit** *(development)* | Understanding the codebase “as is”, section by section. |
| **Development tools** *(development)* | Preparing the build/tests — the project’s “baseline”. |
| **Ask** | Read-only questions about the company’s documents or the code: an answer with a link to a page, file, ticket or knowledge base entry. See [Ask](/en/docs/ask). |
| **Deep research** | Two agents (an analyst and a reviewer) prepare a verified document from the company’s documents or the code. See [Deep research](/en/docs/research). |
| **Tokens** | The model’s usage: input, cache, output, reasoning — see **Token** above. |