# Core concepts > Organisation, project and space, repository and knowledge sources, task, subtasks, review. A short map of the product’s entities. Full definitions are in the [Glossary](/en/docs/glossary). Sections marked “for development projects” do not occur in a space without code. ## Organisation and members An **organisation** is a team’s isolated space. It has an **owner** and **members**; one organisation’s data and traffic are not accessible to another. You can create organisations and switch between them. ## Development project and repository - **Repository** — an imported mirror of your external git repository (upstream). - **Development project** — a project that gathers one or more repositories as **sources** (`repo@branch`) and in which development takes place. - **Connector** — an agent you run in your own network: it connects git that is not reachable from the internet (self-hosted behind a firewall) or spares you from handing us access tokens, and it also runs integrations with trackers and knowledge sources on your side. More in [Connector](/en/docs/connector). ## Space and knowledge sources - **Space** — a workplace **without code**: questions, deep research and a knowledge base built on the department’s documents. For support, sales, legal, HR, finance, marketing, management, product managers and analysts; it does not turn into a development project. As a scope for permissions and entries it works like a project. See [A space without code](/en/docs/quickstart/space) and the [Buff without a repository](/en/docs/no-code) track. - **Knowledge source** — a connection through which the AI agent reads documents where they live: Notion, Confluence, Google Drive, files on a server and network folders, Figma, and optionally the internet. Nothing is copied in advance: only what was needed for the answer is read, and only within the connection’s scope: in the selected sections, or, if nothing is selected, in whatever the account can access (for the internet, empty lists mean the whole public internet, see [The web for the model](/en/docs/connector/web)). See [Knowledge sources](/en/docs/connector/knowledge). - **Question** (“Ask”) and **research** — the units of work in a space: an answer in a conversation with links to documents, or a verified document in which a second agent has checked every claim against the sources. See [Question or research?](/en/docs/ask-vs-research). - The **AI agent** only reads documents; what it writes is the answer, the research document and knowledge base entries. A system that is not in the connection catalogue can be connected by the company [with its own tool](/en/docs/connector/custom-mcp). ## Integration and connection The connector is also an integration host, and two different words matter here: - **Integration (plugin)** — this is **code**: a signed bundle from the catalogue that the connector downloads and runs on its side. One integration per system: trackers — Jira (Data Center, Server and Cloud), GitLab, GitHub, Gitea and Forgejo, Bitbucket (Data Center and Cloud — requests in pull requests), Redmine; knowledge sources — Confluence, Notion, Google Drive, Figma, files on disk and network folders; the internet. Besides the catalogue, the connector also runs [your own MCP servers](/en/docs/connector/custom-mcp). - **Connection** — this is the **link** to a specific system: an address, credentials, a list of repositories or projects, and the development project (or space) where the work goes. Two Jira instances are two connections of one integration, with different secrets and different permissions. A connection has a **slug** — a short name derived from its title. It ends up in the names of the tools the model sees, so `jira_prod` and `jira_sandbox` read better than two `jira`s. ## A task and its life (for development projects) A **task** follows a path: **request** → **refinement/formulation** → **decomposition** into **atoms** (subtasks) → **development** in **waves** → **review** → **publishing**. At the key points a person takes over: they approve the plan before the start and approve the result. The **analyst** here is a role of the AI agent, not an employee: it turns the request into a specification and asks the author clarifying questions. In a deep research the same role writes the document that a second agent checks. ## Atoms and waves (for development projects) During decomposition a task is split into **atoms** — the smallest independently buildable units. Atoms are carried out in **waves** in dependency order; you can see this on the [Execution scheme](/en/docs/pipeline/execution-scheme). ## Knowledge base What the organisation knows about itself, apart from the code and from any single task: working rules, facts about the project and pitfalls of the environment. People keep the entries, and the model **reads them at every stage** and **adds to them itself** after finished work. This is what outlives the end of a task: without it every next task starts from a blank page. See [Knowledge base](/en/docs/knowledge). ## Review and findings (for development projects) Finished changes go through **review**: diffs, discussion and **findings** (from the model and from you) with an “approve” or “changes requested” decision. After approval a pull request is opened in the source repository.